Hi all, +1 for this. Not totally because I found this to be using the Registry (:-)...), but this is definitely something very useful - if done properly.
Dulitha, there are several aspects here. 1. User: What kind of Impact does the Translation introduce to the performance of UIs 2. User: How easy is to Translate a Product (as the sole-user or as a tenant of a shared system) 3. Developer: How easy is to make use of localized resources 4. Developer: How well does this fit with existing localization mechanisms, and if not, what's the effort to migrate (Sumedha's question) I believe that our fundamental focus has been around #3, but #1, #2 and #4 are equally important. This is what determines what's the best approach. Before we get into the implementation aspects, do we have a clear understanding of these? Thanks, Senaka. On Tue, Jan 6, 2015 at 10:46 AM, Chathura Dilan <[email protected]> wrote: > Hi Jo, > > I'm +1 to have one translation file for the core and other components > have ability to access it through namespaces for common terms. But IMO > components should have their own translation files, then we can separate > the component independently from the core. To merge translations we should > use the same term in all components which is practically impossible. > > On Mon, Jan 5, 2015 at 11:44 PM, Joseph Fonseka <[email protected]> wrote: > >> 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 <[email protected]> >> 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 <[email protected]> >>> wrote: >>> >>>> Hi Dilan, >>>> >>>> On Mon, Jan 5, 2015 at 3:30 PM, Chathura Dilan <[email protected]> >>>> 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 <[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 >>>>> >>>>> >>>> >>>> >>>> -- >>>> 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 >>>> >>>> >>> >>> >>> -- >>> 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 >>> >>> >> >> >> -- >> >> -- >> *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 >> >> > > > -- > 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 > > -- *[image: http://wso2.com] <http://wso2.com>Senaka Fernando* Solutions Architect; WSO2 Inc.; http://wso2.com *Member; Apache Software Foundation; http://apache.org <http://apache.org>E-mail: senaka AT wso2.com <http://wso2.com>**P: +1 408 754 7388; ext: 51736*; *M: +44 782 741 1966Linked-In: http://linkedin.com/in/senakafernando <http://linkedin.com/in/senakafernando>*Lean . Enterprise . Middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
