Customizing name of localization properties files in hybris - localization

I found this paragraph in hybris documentation:
Name of the localization properties file follows the pattern:
extensionname -locales_ isocode .properties, where isocode is the
identifier of a language in the hybris Commerce Suite. For example:
core-locales_en.properties or category-locales_de_at.properties.
I noticed that in our company code, we use base_isocode.properties files. How can we customize name of localization properties files?

The names of the localisation files are set in the platform - the code explicitly checks for the name of the extension. E.G.
final String locFileName = "/localization/" + extName + "-locales_" + lang.getIsoCode().toLowerCase() + ".properties";
I'd argue that this is a case where it's significantly easier to go for convention (and follow the naming convention used in the platform) rather than changing core platform code.

Related

ASP.NET MVC add translation in multiplanguage from screen/UI dynamically

In my website -- Add screen/UI from which user can add translation dynamically
for example:
I want to add translation for "Hello World!" in multiple language and want to fetch according to language selection
Key :
strHelloWorld
Value:
Hello World!
Language:
en (it can be anything english,spanish,german etc)
This above 3 field data we can add/enter from Scree/UI by superadmin and
store/save in whatever form is good it can be in database or in json file
Please suggest way to add translation from screen
Asp.Net has a special file called resource files (.resx) to define the default locale (English) and other language texts.
For that please follow the steps:
step 1: You need to create .resx(resource file) into Resource(new
folder). create the file for the default language and second file with other lang.
step 2: set access modifier to public otherwise the
variable value will not appear on the view side
step 3: enter the variable name in the same in both files but make value different related to language.
step 4: once you declare the same variable name in both languages resource file, you can use that variable name where ever you want to declare in .cshtml file.
ex. Resources.Global.APP_NAME
For reference :
http://www.codedigest.com/posts/53/create-multi-language-website-in-aspnet-mvc---localization
Please use below nuget package
It is really awesome thanks to nuget and their author
https://github.com/RickStrahl/Westwind.Globalization
Please note that In this solution they have provided solution for all .net framwork/platform like asp.net 4.5 also aspnet core
Thanks again

Sublime Text 3 - Set syntax for filetype in package/plugin

I am busy making a sublime text plugin/package that will ease development of lua scripts in my workplace.
We have several lua files with different extensions depending on their purpose. I want ST3 to give the proper lua syntax to these files.
I know you can set ST3 to remember syntax for a specific file extension and this is saved as a (in my case) Lua.sublime-settings file in AppData\Roaming\Sublime Text 3\Packages\User
However, if I put this file in my new plugin's folder, it's ignored.
Am I doing something wrong or is what I want not possible?
This doesn't work because syntax specific settings are only loaded from the package that defines the syntax and from the User package (so the user can customize them).
The following is a quote from the official documentation on settings:
Settings files are consulted in this order:
1. Packages/Default/Preferences.sublime-settings
2. Packages/Default/Preferences (<platform>).sublime-settings
3. Packages/User/Preferences.sublime-settings
4. <Project Settings>
5. Packages/<syntax>/<syntax>.sublime-settings
6. Packages/User/<syntax>.sublime-settings
7. <Buffer Specific Settings>
The only places where <syntax> is referenced is from the package itself and from the user package.
If I had to guess, I would say that this is because outside of the original package author that defined the syntax, all other settings would be considered user customizations, and those settings need to be in the User package (specifically in the root of it) to ensure that they're loaded last.
A simple (but undesirable) solution would be to document for the user that they have to take this step manually.
Another approach would be to add some plugin code that extends the settings when your plugin is loaded:
def plugin_loaded():
settings = sublime.load_settings("Lua.sublime-settings")
extensions = settings.get("extensions", [])
if "blarb" not in extensions:
extensions.append("blarb")
settings.set("extensions", extensions)
sublime.save_settings("Lua.sublime-settings")
If you go this route you may want to include an extra sentinel setting somewhere (in settings specific to your package or some such) that says if you did this or not instead of just forcing the setting in as the example above does.
In practice you would then check if you've set that sentinel or not instead of forcing the extension in, so that if the user decides to use some other syntax for your files you're not forcing them into the Lua syntax.
It's also possible to define your own syntax that just embeds the standard Lua syntax, which allows this to Just Work™ without having to write any code or have the user do anything:
%YAML 1.2
---
name: Blarb
scope: source.lua
file_extensions:
- blarb
contexts:
main:
- include: scope:source.lua
When you do this, the scope in the file will still be source.lua because that's what the scope in the syntax file says. and the status line will set the syntax name to Blarb. You could modify either of those to change the top level scope or displayed name, if desired.
An example would be to change the scope to source.blarb so that you could create key bindings/snippets that only apply to Lua files of your specific variant.
A potential downside/feature of this is that since the name of the syntax specific settings comes from the name of the file that provides the syntax, if the user has any Lua specific settings, they won't apply to your Blarb files by default.
Similarly anything that's specific to Lua by checking for a scope of source.lua won't work in Blarb files for same reasons, which may or may not be an issue.

Best way to utilize strings in iOS

I am new to coding in Objective-C, but am coming from the Java world of mobile development. In Android, we use a strings resource, and then point to those in the Java class. Is there an analogous process in iOS that we should be using, or do we "hard-code" the strings into the implementation files? I haven't yet found a good tutorial using the localizable string (and .strings) file.
You can use the NSLocalizedString macro from Foundation to retrieve a localized string. Read here:
http://www.icanlocalize.com/site/tutorials/iphone-applications-localization-guide/
Example: build a bilingual (English-French) app.
Whenever you encounter a string to be displayed to the user, use NSLocalizedString instead of the actual string constant. For example:
instead
self.title = #"Welcome";
use
self.title = NSLocalizedString(#"Welcome");
Create two directories inside your app bundle as follows:
MyApp.app
English.lproj
Localizable.strings
French.lproj
Localizable.strings
In the first Localizable.strings file you can write key-value pairs like this:
"Welcome" = "Welcome";
In the second one:
"Welcome" = "Bienvenus";
When you add these files and folders to your application, an recompile it using the NSLocalizedString macro, you'll be able to use your app in French also when the system language is French.
Sure, there's a way to do that.
Take a look at the Apple doc here - http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/LoadingResources/Strings/Strings.html
There's not much more to it than that really. Although I tend to just hard code a lot of strings but it's definitely worth taking the time to learn about string resources because it's the basis of internationalisation.

Localizing strings from the Settings.bundle using InAppSettingsKit

I am attempting to use InAppSettingsKit to manage my settings. This uses the Settings.bundle with a .plist file and the .strings files for each of the languages being translated.
I can confirm that the translation of my strings is working properly outside of my application, using the Setting application. But when I am in my application, the translation is not occurring.
I think it comes down to code like this, from the InAppSettingsKit class IASKSettingsReader, with a couple logging statements that I thought my be helpful:
- (NSString*)titleForStringId:(NSString*)stringId {
NSLog(#"%#",[_bundle localizedStringForKey:stringId value:stringId table:self.localizationTable]);
NSLog(#"%#",[_bundle localizedInfoDictionary]);
return [_bundle localizedStringForKey:stringId value:stringId table:self.localizationTable];
}
If I understand correctly, this should be using a table with the name self.localizationTable as the source of the translation. This value is simply "Root". It's not a path to the Root.strings file in the selected language, so I am guessing that the method localizedStringForKey:value:table: must be using some global system reference that points to the correct path.
I have confirmed that the strings file name is "Root.strings" all around, with a capital R, including in the Root.plist file.
[_bundle localizedInfoDictionary] returns (null); It is doing this for two language settings of English and French.
I'm not sure how to debug this. Thanks for any help you can give.
I'm using InAppSettingsKit with localized text with no problems. Two things I can think of that you could check: are your Root.strings files located in the correct subdirectories of Settings.bundle (en.lproj and fr.lproj for English and French?
Is there a "Strings Filename" entry in your Root.plist? It should simply contain a string with value "Root"
It has been quite some time since I resolved this, and at the time, I didn't fully understand it. But, in the interest of closing out this question, I'll point to the following documentation for future reference:
NSBundle Class Reference
which refers to the following:
Resource Programming Guide
In the second document, refer to the section "String REsources -> Loading String Resources Into Your Code"
The solution contains a properly configured Root.strings file, which shows up in the file list like this:

how to get locale information on a GWT application

In GWT I have to specify what locales are supported in my application. The code get compiled in various files, one for each locale (beside other versions), but I have to give my clients one only URL. This URL is supposed to be a page that should be displayed according to the locale preferred by the browser.
I dont't want to have an HTTP parameter for the locale since I want to forse the locale preferred by the browser.
How can this be coded in GWT?
Should I try to to this using apache rewrite rules? I thied it, but I think I cannot access such parameter easely in a rewrite rule.
Thanks a lot,
Giuseppe
I had the same problem as you, but as I really need to know the current locale (I'm requesting a second server for data that I want to be localizable) I found this class:
com.google.gwt.i18n.client.LocaleInfo#getCurrentLocale(). That should give you what GWT uses currently.
GWT has good support for internationalization. See this link. The i18nCreator command can help you to set up the internationalization infrastructure for similar to the way projectCreator and applicationCreator set up the GWT application.
If you have static strings (i.e. Invalid Entry!) that need to be internationalized, you don't need any additional flag to i18nCreator command to create the properties files and infrastructure.
If you have strings that need to accept parameters (i.e. Hello {0}), you need to pass the -createMessages flag to i18nCreator command to create the properties files and infrastructure.
Now your module needs to include the i18n module in your MyApplication.gwt.xml:
<inherits name="com.google.gwt.i18n.I18N"/>
Define a Java interface in the same package as your property files that extends Constants or Messages and defines methods (name matches the property entries) that all return string.
MyConstants.properties contains:
errorMessage=Invalid Entry!
MyConstants.java contains:
import com.google.gwt.i18n.client.Constants;
public interface myConstants extends Constants {
String errorMessage();
}
Now to access these internationalized Strings from you application:
public class MyApplication implements EntryPoint {
private static final MyConstants constants = (MyConstants)GWT.create(MyConstants.class);
public void onModuleLoad() {
final Label errorMessage = new Label(constants.errorMessage);
}
}
GWT implements the interface for you automagically.
You can get messages in a similar way.
Hopefully this can help you get started.
Unless I am reading the documentation incorrectly I don't think you have to do anything.
GWT and Locale
By making locale a client property, the standard startup process in gwt.js chooses the appropriate localized version of an application, providing ease of use (it's easier than it might sound!), optimized performance, and minimum script size.
The way I read it, as long as your module has added all the locale choices to it, it should be automatic?
Check this com.google.gwt.i18n.client.LocaleInfo.getCurrentLocale()
<inherits name="com.google.gwt.i18n.I18N"/>
<!-- Use browser-specified locale for i18n -->
<set-configuration-property name="locale.useragent" value="Y"/>
<!-- Specify locales your application support -->
<extend-property name="locale" values="en"/>
<extend-property name="locale" values="de_DE"/>
<extend-property name="locale" values="ru_RU"/>

Resources