Hi Chathura Translating independently per component will redundant lot of work. If we want to follow that path need the capability to merge translated terms from other components.
IMO it will be more suitable to aggregate the terms from components and make a single translation file per product. Also if we can merge translations from other products to reduce the translation efforts. ( Ex same terms can be found in many of the products ) Regards Jo On Mon, Jan 5, 2015 at 3:28 AM, Chathura Dilan <chathu...@wso2.com> wrote: > Hi Johann, > > +1 for that. That could be a language file/bundle for a component or the > core, but it should be translated independently using standard translation > tools. > > On Mon, Jan 5, 2015 at 3:37 PM, Johann Nallathamby <joh...@wso2.com> > wrote: > >> 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 >> >> > > > -- > 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 > > -- -- *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
