Hi Dilan, On Mon, Jan 5, 2015 at 3:30 PM, Chathura Dilan <chathu...@wso2.com> wrote:
> 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. > Components having different files is OK for component developers. In this case we are talking about a tenant admin who does not have any access to filesystem, adding and changing some templates used by those components. So it is a must that we have a UI component for that. > > On Sat, Dec 20, 2014 at 4:18 AM, Dulitha Wijewantha <duli...@wso2.com> > 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 <jos...@wso2.com> 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 <joh...@wso2.com> >>> wrote: >>>> >>>> This would be a valuable feature Dulitha. >>>> >>>> On Fri, Dec 19, 2014 at 7:11 AM, Dulitha Wijewantha <duli...@wso2.com> >>>> 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 duli...@wso2.com <duli...@wso2mobile.com>* >>>>> * ~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 >>>>> Architecture@wso2.org >>>>> 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 >>>> Architecture@wso2.org >>>> 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 >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> -- >> Dulitha Wijewantha (Chan) >> Software Engineer - Mobile Development >> WSO2 Inc >> Lean.Enterprise.Mobileware >> * ~Email duli...@wso2.com <duli...@wso2mobile.com>* >> * ~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 >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Regards, > > Chatura Dilan Perera > *(Senior Software Engineer** - WSO2 Inc.**)* > www.dilan.me > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > 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 Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
