Each components should have its own localization file. It can be accessible from its namespace. I think for files it is best thing to use standard file formats such as .properties, .po or there should be a way to convert them to standard file format vice versa. So translations can be done independently.
User should have ability to select his/her language or otherwise a generic language can be used. And there should be a way to have the default text when you define the translation. also you need to consider about the parameters which sends along with the translations. I haven't worked with gettext, but it is worth to look at gettext (it seems cool) before creating our own library. On Sat, Dec 20, 2014 at 4:18 AM, Dulitha Wijewantha <[email protected]> wrote: > Hi guys, > The i18n support in jaggery is about providing i18n support for web apps. > This proposition is to provide a platform wide solution so in Java & > Jaggery we can both use. Current implementation of jaggery i18n support [1] > does this through json files stored in the web app. My other comments are > inline - > > [1] - > https://github.com/wso2/jaggery-extensions/blob/master/i18n/module/scripts/i18n.js > > Cheers~ > > On Thu, Dec 18, 2014 at 11:22 PM, Joseph Fonseka <[email protected]> wrote: >> >> Hi All >> >> My personal experience with i18n library is that its difficult to >> maintain the code and to translate. >> >> IMO what should be looked in a localization library is how easy it is to >> maintain the localized code and to translate. So far the best experience I >> had was with the Gettext[1] library. >> >> Some of the advantage with gettext >> 1. Wide set of tools to help translate like string extraction tools and >> translating apps [2]. >> 2. Fuzzy matching. >> 3. Plural support. >> 4. Reusing already translated strings from other apps. >> >> IMHO we should give gettext a try to see if it can make l10n easy for us >> in the platform or at least for webapps. >> > I don't quite understand what you said. i18n doesn't perform any > translation right? It does matching for key and chose it from a locale > file. Does gettext perform translation to text? > > >> >> Regards >> Jo >> >> [1] https://www.gnu.org/software/gettext/ >> [2] http://poedit.net/ >> >> >> On Fri, Dec 19, 2014 at 9:55 AM, Johann Nallathamby <[email protected]> >> wrote: >>> >>> This would be a valuable feature Dulitha. >>> >>> On Fri, Dec 19, 2014 at 7:11 AM, Dulitha Wijewantha <[email protected]> >>> wrote: >>>> >>>> Hi guys, >>>> I have been thinking about localization for bit and thought the >>>> traditional localization method using .properties file and ResourceBundle >>>> wouldn't be much of help considering the way we have components. There is >>>> also a known set of disadvantages using ResourceBundles [1]. >>>> >>>> Use cases I see are below >>>> 1) Localize the product based on a configuration >>>> 2) Localize components based on user preference. >>>> >>>> Both these aspects depends on the component - for example API Store >>>> should support a way for the user to view the store in different language. >>>> For IS - it should send emails in the user's preferred language. For CDM - >>>> the license for agents should be presented to the user on preferred >>>> language. >>>> >>> >>> One of the key differences in the IS use case is displaying dynamic >>> content. The email template is not fixed. The admin can go and change the >>> template at will. So I think its bit special than the other two use cases >>> you've mentioned. WDYT ? >>> >> Actually this where I go this idea from :) . There is a method to obtain > a localized file (which is stored in registry). All we have to do is to > give the admin an interface to go and change the file in registry. Even for > the dynamic content it will work cause we will have an email template for > each language. > > > >> >>>> So my proposal is to make a LocalizationManagerUtil using registry as >>>> the persistence for the locale files. This Util class will have below 2 >>>> methods >>>> >>>> 1) getLocalizedFile(String fileName, Locale locale) >>>> 2) getLocalizedString(String namespace, String key, Locale locale) >>>> >>>> getLocalizedFile() method will be used to load templates/files that a >>>> specific to languages - examples would be terms and conditions, policies, >>>> email templates etc. Behind the scene these will be stored in the registry >>>> and served based on the localization requested. >>>> >>>> getLocalizedString() method will be used to load strings that are >>>> presented to the users. This method takes a namespace so that we can >>>> partition it based on a component/product. >>>> >>>> Also these methods will use the global locale in case the locale is not >>>> sent to the method. Few questionable aspects I have are below >>>> >>>> - Errors - how to handle if a string for a locale is not found >>>> - Loading/Reloading locals from files for the first to the registry >>>> >>>> Not clear what you meant here. What I am thinking is there should be a >>> separate admin module for this. In Carbon management console it could be a >>> separate menu item under configure tab probably. Or in APIM it could be the >>> admin dashboard which is used to upload themes and all. Wherever it is what >>> I am thinking is, users should be able to define strings and upload files >>> for different locales. >>> >> +1. For the first time - our by default supported langs will be loaded > from config directory. User can upload his lang files and change templates > and strings from a UI. > >> >>>> - Where in registry to store the files >>>> - Performance and caching >>>> >>>> I started a POC level implementation on CDM core utils [2]. WDYT guys? >>>> >>>> [1] - http://www.javapractices.com/topic/TopicAction.do?Id=208 >>>> [2] - https://gist.github.com/dulichan/ef99784e5a6e5332e5c1 >>>> >>>> Cheers~ >>>> >>>> -- >>>> Dulitha Wijewantha (Chan) >>>> Software Engineer - Mobile Development >>>> WSO2 Inc >>>> Lean.Enterprise.Mobileware >>>> * ~Email [email protected] <[email protected]>* >>>> * ~Mobile +94712112165 <%2B94712112165>* >>>> * ~Website dulitha.me <http://dulitha.me>* >>>> * ~Twitter @dulitharw <https://twitter.com/dulitharw>* >>>> *~Github @dulichan <https://github.com/dulichan>* >>>> *~SO @chan <http://stackoverflow.com/users/813471/chan>* >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> -- >>> Thanks & Regards, >>> >>> *Johann Dilantha Nallathamby* >>> Associate Technical Lead & Product Lead of WSO2 Identity Server >>> Integration Technologies Team >>> WSO2, Inc. >>> lean.enterprise.middleware >>> >>> Mobile - *+94777776950* >>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>* >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> -- >> >> -- >> *Joseph Fonseka* >> WSO2 Inc.; http://wso2.com >> lean.enterprise.middleware >> >> mobile: +94 772 512 430 >> skype: jpfonseka >> >> * <http://lk.linkedin.com/in/rumeshbandara>* >> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > -- > Dulitha Wijewantha (Chan) > Software Engineer - Mobile Development > WSO2 Inc > Lean.Enterprise.Mobileware > * ~Email [email protected] <[email protected]>* > * ~Mobile +94712112165 <%2B94712112165>* > * ~Website dulitha.me <http://dulitha.me>* > * ~Twitter @dulitharw <https://twitter.com/dulitharw>* > *~Github @dulichan <https://github.com/dulichan>* > *~SO @chan <http://stackoverflow.com/users/813471/chan>* > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Regards, Chatura Dilan Perera *(Senior Software Engineer** - WSO2 Inc.**)* www.dilan.me
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
