Is the Struts2 file applicationRessource.properties can be in another locale than English. I know I can have some other files like ApplicationRessource_fr.properties or ApplicationRessource_es.properties.
My main questions concern only the ApplicationRessource.properties. My default language will be French and I don't want to have a file like ApplicationRessource_fr.properties. Is there a way to do that?
You must have a file like ApplicationRessource_fr.properties if you want to use French locale. You can also have a default language file which will be used if no locale is requested. The essential part of the application include the interceptor to intercept the requested locale, you can also switch the locale per request.
It's likely no i18n interceptor on the action stack or you don't have
resource bundles for the used locale or default locale used by the
JVM.
Essentially, the i18n Interceptor pushes a locale into the ActionContext map upon every request. The framework components that
support localization all utilize the ActionContext locale.
Here was the solution we found. We use 3 files. ApplicationRessource.properties who are in french, ApplicationRessource_fr.properties who is empty and ApplicationRessource_en.properties who contains the english translations
Related
We are facing a strange behaviour with the handling of NSLoaclizedString with our bundle strings file.
We have maintained our strings file in:
de_AT (german in Austria)
de_DE (german in Germany)
We didn't setup any base/default strings file since we usually wan't to define per region which strings file should be used. So
Region Poland should use de_DE
Region Italy should use de_AT
During our tests we just recognized that NSLocalizedString just takes the first bundle (de_AT) independant of any Locale if the locale doesn't match.
Is there any way to define/control for which Locale we want to see the translations?
We only found a parameter "tableName" for the language, but no language & country specific locale... we don't want to create Localizable.strings for every available combination of language & country.
Thanks!
Ok we researched a lot, our current solution is to create independant Localizable.strings file and name them per locale:
de_AT.strings
de_DE.strings
Based on our mapping logic we do then set the right bundleName...
I install Orchard CMS 1.10 and take russian translate from https://crowdin.com/project/orchard-cms and unpack to Orchard.Web. When i added and enabled ru-Ru localization all work good for razor views. But for module isn't. For example i try change validate message for required fields in Orchard.DynamicForms, but nothing happened when displayed validation message, they still english. Also translate not applied for module list in admin panel.
Search for the english message in source code, add breakpoint and step into the T() call, then check the value of the scope parameter. This is the value that should be used in the msgctext line.
Like the asker of the question here
Variable substitution JSF Resource Bundle property file
I'm slightly aghast at the inability to reference the value of other property keys in the message bundle.
Although I see how easy to write my own rubbish handler[0] that can do what I want in a custom component, that would leave expressions in templates calling the message bundle still using the default JSF implementation.
Is it possible to override the default JSF handling of the message bundle?
[0] Or better, to use code referenced in one of the answers to the above question
https://code.google.com/p/reflectiveresourcebundle/
You can provide the fully qualified name of a concrete ResourceBundle implementation as "base name" instead of alone the path and filename of the properties files.
E.g.
public class YourCustomResourceBundle extends ResourceBundle {
// ...
}
which can be registered as follows
<application>
<resource-bundle>
<base-name>com.example.YourCustomResourceBundle</base-name>
<var>text</var>
</resource-bundle>
</application>
or declared on a per-view/template basis as follows
<f:loadBundle baseName="com.example.YourCustomResourceBundle" var="text" />
Here are several related questions/answers which contain some concrete code which you could use as a kickoff example:
How to remove the surrounding ??? when message is not found in bundle
internationalization in JSF with ResourceBundle entries which are loaded from database
i18n with UTF-8 encoded properties files in JSF 2.0 appliaction
Everything is possible for those who try. The question is not whether it is is possible but should you do it. And the answer to that question is: probably not.
Referencing other message in a message bundle means you want to build a compound message. So you can re-use part of the message many times just to save small fraction of the disk space or small fraction of development time.
If that is the case, I have a message for you. What you plan to do is called a concatenation and it is the second most common I18n defect. And its implications are as bad as those of hardcoded strings.
Why? Because target languages do not follow the English grammar rules. First, it is common need to re-order the sentence while translating. This might be easy to fix by using (numbered or named) placeholders. On the other hand though, the translation might differ depending on the context. That is, it might need to be translated in totally other way, or simply the word endings might need to be different depending on a grammar case, mood or gender.
My advice is, do not use such shortcuts, it will create more problems than it fixes.
Now you should know why "those stupid Romans" didn't implement it like this: it is against I18n best practices.
In a tutorial on setting up internationalization and localization, "Kohana 2.4 I18N (internationalization and localization) Library" the author says:
I'd put it in a Base Controller so that all Controllers inherit it.
This is the code:
I18n::set_locale('tl_PH');
I tried placing it in all the controller and places I could but is not working.
Where is the exact place in Kohana 3.0.4.2 that I should place it?
Put this line in bootstrap.php:
I18n::lang('tl-PH');
The I18n::set_locale function doesn't exist in Kohana 3. See I18n class docs.
Not sure who wrote that article, but locale should be set using the config locale.php config file. You may have to copy it from system/config/locale.php into your application/config/locale.php and set the proper values.
Calling I18n::set_locale() should only happen if you need to change from the default (set in locale.php) to something different (like Dutch, English, etc...).
P.S I'm a Kohana 2.4 core dev...
If you want to set the PHP locale, you will change this is in application/bootstrap.php, there is a setlocale(LC_ALL, 'en_US.utf-8') line there already which you can change to the correct language.
To set Kohana's internal language for translation, add a call to I18n::lang('en-us') (replace "en-us" with your language) after the Kohana::init() call, before Route::set().
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"/>