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
