Difference between revisions of "Opentaps 2 i18n"
(New page: == Internationalization == Adding string resources in the national languages can be implemented in the same way as in the most of Java programs. Strings in the properties file should be s...) |
(→Internationalization) |
||
| (2 intermediate revisions by one other user not shown) | |||
| Line 3: | Line 3: | ||
Adding string resources in the national languages can be implemented in the same way as in the most of Java programs. Strings in the properties file should be stored in a place available for classloader of the bundle. ResourceBundle class is well-known for developers and it can be used to retrieve strings. But since applications run on OSGi a developer can be able to add a new translation without changing the source code through the fragments. | Adding string resources in the national languages can be implemented in the same way as in the most of Java programs. Strings in the properties file should be stored in a place available for classloader of the bundle. ResourceBundle class is well-known for developers and it can be used to retrieve strings. But since applications run on OSGi a developer can be able to add a new translation without changing the source code through the fragments. | ||
| − | Let's consider org.opentaps.notes.rest module as example. Package org.opentaps.notes.rest.locale contains everything you need so you can return an error message in the national languages. Messages class implements a set of methods for easy access to string resources. messages.properties contains strings in default language. Eventually you can add other languages here, but if your intention is not to install all languages at once, or sources are not available, simply create a fragment bundle and place new translation (s) there. This fragment bundle should have symbolic name of the main module in manifest header <tt>Fragment-Host</tt> and contains new properties in the same package as host bundle. Examples of French and Russian translations are in org.opentaps.notes.rest_fr | + | Let's consider org.opentaps.notes.rest module as example. Package <tt>org.opentaps.notes.rest.locale</tt> contains everything you need so you can return an error message in the national languages. <tt>Messages</tt> class implements a set of methods for easy access to string resources. <tt>messages.properties</tt> contains strings in default language. Eventually you can add other languages here, but if your intention is not to install all languages at once, or sources are not available, simply create a fragment bundle and place new translation (s) there. This fragment bundle should have symbolic name of the main module in manifest header <tt>Fragment-Host</tt> and contains new properties in the same package as host bundle. |
| + | |||
| + | Examples of English, French, and Russian translations are in the file <tt>src/main/resources/org/opentaps/notes/rest/locale/messages.properties</tt> in the <tt>org.opentaps.notes.rest</tt>, <tt>org.opentaps.notes.rest_fr</tt>, <tt>org.opentaps.notes.rest_ru</tt> bundles. You can deploy these bundles as soon as you need a supported language regardless of the main application. | ||
Also, method <tt>Messages.getInstance(Request)</tt> may be interesting. Since Notes REST is a web application, then every next request may require the support of different languages. The most reliable way for the customers to specify their language preferences is locale encoded in URL following the pattern <tt>/notes/<locale>/note/<ID></tt>, for example <tt>/notes/fr/note/XXXXX</tt>. <tt>getInstance()</tt> method checks this parameter, but if it is missing then analyze languages listed in the Accept-Language header and the first available is used to load the resource. | Also, method <tt>Messages.getInstance(Request)</tt> may be interesting. Since Notes REST is a web application, then every next request may require the support of different languages. The most reliable way for the customers to specify their language preferences is locale encoded in URL following the pattern <tt>/notes/<locale>/note/<ID></tt>, for example <tt>/notes/fr/note/XXXXX</tt>. <tt>getInstance()</tt> method checks this parameter, but if it is missing then analyze languages listed in the Accept-Language header and the first available is used to load the resource. | ||
Latest revision as of 18:57, 17 February 2012
Internationalization
Adding string resources in the national languages can be implemented in the same way as in the most of Java programs. Strings in the properties file should be stored in a place available for classloader of the bundle. ResourceBundle class is well-known for developers and it can be used to retrieve strings. But since applications run on OSGi a developer can be able to add a new translation without changing the source code through the fragments.
Let's consider org.opentaps.notes.rest module as example. Package org.opentaps.notes.rest.locale contains everything you need so you can return an error message in the national languages. Messages class implements a set of methods for easy access to string resources. messages.properties contains strings in default language. Eventually you can add other languages here, but if your intention is not to install all languages at once, or sources are not available, simply create a fragment bundle and place new translation (s) there. This fragment bundle should have symbolic name of the main module in manifest header Fragment-Host and contains new properties in the same package as host bundle.
Examples of English, French, and Russian translations are in the file src/main/resources/org/opentaps/notes/rest/locale/messages.properties in the org.opentaps.notes.rest, org.opentaps.notes.rest_fr, org.opentaps.notes.rest_ru bundles. You can deploy these bundles as soon as you need a supported language regardless of the main application.
Also, method Messages.getInstance(Request) may be interesting. Since Notes REST is a web application, then every next request may require the support of different languages. The most reliable way for the customers to specify their language preferences is locale encoded in URL following the pattern /notes/<locale>/note/<ID>, for example /notes/fr/note/XXXXX. getInstance() method checks this parameter, but if it is missing then analyze languages listed in the Accept-Language header and the first available is used to load the resource.
