On Sun, Mar 27, 2011 at 10:47 PM, Senaka Fernando <[email protected]> wrote:
> Hi Pradeeban, > > Just saw that you asked a question from me. For JSPs, you need to add > > <%@ page contentType="*text/html;charset=UTF-8*" language="java" %> > > at the very top. Next, for Ajax.update/Ajax.request there was one of the > two that mixed up the encoding, so you might need to check on that aspect. > If it mixes up, the resulting page loaded asynchronously will have '?' > symbols. Once that's done, if you have done any encoding/decoding, ensure > that it is UTF-8 and not anything else. > > That's three things. The fourth is for languages that has transliteration > (like Japanese - I tried for that). In there, the transliteration process > generates some keystroke sequences which can be trapped in JS. If you've > written JS event handlers that get triggered on keypress, please note and > fix them as appropriate. > > Thanks for your explanation and suggestions Senaka. They are really useful. > Fifth is @ DB-schema level. Some products store data into DBs. We need to > ensure that it can store UTF-8 data. Most of our schemas are written with > this in mind but better check. Sixth are the regular expressions that we > have. Some don't allow non-latin input. In my scenario, I wanted to have > Japanese usernames and passwords. The UM regex had to be fixed to support > that aspect. Guess its not broken again, but better check. > I am more interested in a localized interface. Except for the few specific cases, I don't think many users really expect to have usernames and passwords in their local languages (I meant the need for the unicode-only-language username and password). A localized user interface is what most are interested, acc. to my observation and the mails. > > These six things made it possible for me to run a Japanese version of > G-Reg. > > Having said that, it is not practical for someone to edit multiple Jar > files in order to create a localized version of the product. +1. > We need some script. I was thinking about something like this. > > 1. Script will find all (JS)Resources.properties files and create localized > copies (JS)Resources_foo_CC.properties (inside Jars). > > 2. Script will read all localized copies and produce a single file with all > i18n keys which the user would translate. > > 3. Human translation process. > > 4. Script will use the translation and then fix all references in the > localized copies inside Jars. > > Script can be some Java code + sh/bat. IMO, this makes life easy. WDYT? > I agree, if a user wants to add a new translation to the existing binary, a script may be useful to copy his translation to the existing product. I am more suggesting having all the localized property files in the source code itself, hence when building the product, they are placed in the relevant place, eliminating the need for the script when we are building from the source, with the localized resources in place. Here, based on the input param it will chose the relevant properties file from the jars (default being the EN_US). That means, we will still have Resources.properties, which is equivalent to Resources_EN_US.properties. So in this way, we will have multiple property files, *_CC_LL.* living together and it will work out of the box, without going for a script to find the properties files, if the localization is contributed back to the WSO2 Carbon . Thank you. Regards, Pradeeban. > Thanks, > Senaka. > > On Sun, Mar 27, 2011 at 12:17 PM, Kathiravelu Pradeeban < > [email protected]> wrote: > >> >> On Sun, Mar 27, 2011 at 11:55 AM, Guillaume Devianne <[email protected] >> > wrote: >> >>> Great! >>> >>> As I recall, it uses the ResourceBundle >>> http://download.oracle.com/javase/tutorial/i18n/resbundle/propfile.html >>> >>> Also, (to be verified for accuracy), there are 3 levels of resources, >>> >>> 1. default resource eg: Resources.properties >>> 2. language only resource eg:Resources_en.properties >>> 3. language and country resource eg: Resources_en_GB.properties >>> and Resources_en_US.properties >>> >>> >> +1. >> Thanks a lot for your suggestions Guillaume. >> >> If you implement that, one could look at the code and, for example, >>> if there is no Spanish property file, create both Resources_es.properties >>> and Resources_es_CL.properties >>> Then, if a Mexican wants to help, he can eventually create >>> the Resources_es_MX.properties if it is needed. >>> >>> Exactly. I feel we didn't think this much earlier regarding the >> localization. As with the huge interest shown in using WSO2 products in >> other languages, (specially Spanish and Chinese according to the user >> mails), I can clearly say, these improvements will help a lot of users as of >> now. >> >> Currently I am in the process of documenting the current localization >> methodology (which is pretty much covered in this mail thread itself), as a >> resource for the users who try to localize the WSO2 products. >> >> [CC'ing to carbon-dev and stratos-dev for the wider audience]. >> >> >> Thank you. >> Regards, >> Pradeeban. >> >> >> >>> >>> Cheers >>> >>> Guillaume >>> >>> >>> >>> On Sun, Mar 27, 2011 at 1:11 AM, Kathiravelu Pradeeban < >>> [email protected]> wrote: >>> >>>> >>>> >>>> On Sun, Mar 27, 2011 at 5:50 AM, Guillaume Devianne < >>>> [email protected]> wrote: >>>> >>>>> Pradeeban, >>>>> >>>>> Hi Guillaume, >>>> >>>> Funny I looked into localizing Identity Server today. >>>>> I found Resources.properties and JSResource.properties to be changed >>>>> in different places. >>>>> >>>> >>>> I agree, we have to change it in all the ui bundles. >>>> >>>>> >>>>> I know I can just change the words in those files and restart the >>>>> server, but I thought that the "correct" way to do it is to create a copy >>>>> of >>>>> those files and name them : >>>>> >>>>> Resources_es_CL.properties >>>>> >>>>> es:español and CL being Chile (where I live). >>>>> >>>> >>>> +1. I have worked in many open source projects, where they have LL_CC.* >>>> format (Language_Country, for eg: EN_GB.properties). >>>> >>>>> >>>>> >>>>> That way, you could add those files to ehe source code and have spanish >>>>> for chile along with the english, chinese, Sinhala versions. >>>>> >>>>> What is the way that is implemented in Carbon products? >>>>> >>>> >>>> Here we are reading the properties files, and getting the relevant >>>> strings for the keys. The change that you propose is doable. I have created >>>> a jira (CARBON-9183 <https://wso2.org/jira/browse/CARBON-9183>) to >>>> track this. >>>> >>>> Thanks for your effort in localizing WSO2 Carbon, and thanks a lot for >>>> your suggestion. I will have a look more. >>>> >>>> Thank you. >>>> Regards, >>>> Pradeeban. >>>> >>>>> >>>>> Guillaume Devianne >>>>> >>>>> On Fri, Mar 25, 2011 at 12:56 AM, Kathiravelu Pradeeban < >>>>> [email protected]> wrote: >>>>> >>>>>> Hi, >>>>>> I have been experimenting with WSO2 Stratos Manager for a howto on >>>>>> localizing wso2 carbon based products. >>>>>> >>>>>> For that, I had to localize the Resources.properties and >>>>>> JSResources.properties files in locations like when coming to localize >>>>>> the >>>>>> source, even before building. >>>>>> >>>>>> But obviously what users choose is to localize the product binaries. >>>>>> So I had to localize the .properties files in ui bundle jars in >>>>>> repository/components/plugins. For example, attached is the >>>>>> Resouces.properties in org.wso2.stratos.tenant.mgt.ui-1.0.0.jar >>>>>> (/org.wso2.stratos.tenant.mgt.ui-1.0.0/org/wso2/stratos/tenant/mgt/ui/i18n) >>>>>> localized to Spanish (Pls tolerate my poor Spanish knowledge. This is >>>>>> just >>>>>> experimental). >>>>>> >>>>>> After localizing the relevant .properties files (basically changing >>>>>> the value string from English to Spanish, in the key=string pair in the >>>>>> relevant files), I restarted Stratos Manager. >>>>>> >>>>>> The localized interface was shown in Spanish. But there were some >>>>>> issues in displaying the Unicode characters. They weren't displayed >>>>>> properly >>>>>> (Pls find the attached image) . >>>>>> >>>>>> Pls note, we were able to experimentally localize WSO2 Appserver (and >>>>>> some other products too may be) to unicode only languages before >>>>>> successfully. So either I must be missing something or some issue from >>>>>> the >>>>>> internationalization of the interface of Stratos Manager (Unicode >>>>>> rendering >>>>>> issues from the UI). >>>>>> >>>>>> Senaka mentioned he had to fix a few ui issues to make the WSO2 GReg >>>>>> to globalize properly. Senaka, could you pls provide us the steps to fix >>>>>> this, so that we can learn that from you. >>>>>> >>>>>> >>>>>> Thank you. >>>>>> Regards, >>>>>> Pradeeban. >>>>>> >>>>>> -- >>>>>> Kathiravelu Pradeeban. >>>>>> Software Engineer. >>>>>> WSO2 Inc. >>>>>> >>>>>> Blog: [Llovizna] http://kkpradeeban.blogspot.com/ >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Stratos-dev mailing list >>>>>> [email protected] >>>>>> https://wso2.org/cgi-bin/mailman/listinfo/stratos-dev >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Kathiravelu Pradeeban. >>>> Software Engineer. >>>> WSO2 Inc. >>>> >>>> Blog: [Llovizna] http://kkpradeeban.blogspot.com/ >>>> >>>> >>> >> >> >> -- >> Kathiravelu Pradeeban. >> Software Engineer. >> WSO2 Inc. >> >> Blog: [Llovizna] http://kkpradeeban.blogspot.com/ >> >> >> _______________________________________________ >> Carbon-dev mailing list >> [email protected] >> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >> >> > > > -- > *Senaka Fernando* > Product Manager - WSO2 Governance Registry; > Associate Technical Lead; WSO2, Inc.; http://wso2.com* > Member; Apache Software Foundation; http://apache.org > > E-mail: senaka AT wso2.com > **P: +1 408 754 7388; ext: 51736*; *M: +94 77 322 1818 > Linked-In: http://www.linkedin.com/in/senakafernando > > *Lean . Enterprise . Middleware > > -- Kathiravelu Pradeeban. Software Engineer. WSO2 Inc. Blog: [Llovizna] http://kkpradeeban.blogspot.com/
_______________________________________________ Carbon-dev mailing list [email protected] http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
