Skip to main content

Internationalization Support for APIManager apps

This requirement came from some of the users who are already using WSO2 API Manager product and from WSO2 AM 1.3.0 on wards [released on today],this feature has implemented.You can find WSO2 AM 1.3.0 binary pack from here.

Basically for the two apps [Publisher/Store] in WSO2 API Manager,now a developer can change app labels/messages according to the set language in the web browser.

From this blog-post,I'll explain the steps to localize publisher app to Spanish,which contains unicode charactors.

1. First set the browser language to your preferred language.
 Eg: In Google chrome navigate to Settings->Show advanced settings->;Languages and select your preferred language.

2. set the browser encoding type as UTF-8.

3. Then let's change the publisher app accordingly, Extract your downloaded pack and navigate to the deployed publisher app from the location "AM_Home}/repository/deployment/server/jaggeryapps/publisher".

4. We have kept two resource files to define Strings with key as one resource file [eg:locale_en.json] to store the Strings defined in .jag [jagggery] files according to browser locale,while another resource file called 'i18nResources.json' to store Strings defined in client side javascript files such as popping up message strings when an UI event triggerred. You can find the location for these two files from  the above publisher deployment folder with browsing through  'publisher/site/conf/locales'.



5. The jaggery related resource files are located at 'publisher/site/conf/locales/jaggery' folder while javascript resource file is located at   'publisher/site/conf/locales/js' folder.


6. Localize Strings defined in jaggery files

In this blogpost ,since we are going to localize the app with Spanish,first to localize Strings defined in jaggery files,you need to add a new file with your browser set locale value.Say your web browser langauge set to Spanish thus relevant locale code is 'es'. 
Then you have to create a new file called locale_{lolcaleCode}.json [Here that file has to name as locale_es.json] inside 'publisher/site/conf/locales/jaggery' folder  and add the key-value pairs.

Please refer the default resource file for jaggery,that we have added to same above location called 'locale_en.json' and how we have defined key-value pairs for Strings.Below is a part from locale_es.json file I created.


7. Localize Strings defined in client side javascript files

To localize the javascript UI messages,navigate to  'publisher/site/conf/locales/js  and update the json file called "i18nResources.json" with relevant values for the key strings.

That's all.Once you browse changed publisher app view with Spanish,it'll be as below.



Implementation Details
If you much familiar with jaggery apps,you may know that all the strings shown from the app,are defined in either server side jaggery files [.jag files] or in  client side javascript files [.js files]. 

To implement localization support for jaggery,we have used its inbuilt script module called 'i18n' and its functionalities.For more info refer http://jaggeryjs.org/apidocs/i18n.jag

To implement javascript localization support,we have used MIT licensed js plugin called 'i18next' support and it's inbuilt functions.For more info refer http://jamuhl.github.com/i18next/



Comments

  1. jrobinssJanuary 16, 2014 at 3:05 AM

    Hi Lalaji,
    Thanks for the info.
    You don't say, but...
    is there any place on the web where I could find files for each language? Or at least popular languages, such as Spanish, French, ertc?
    thanks!
    Julien Robinson

    ReplyDelete
  2. Lalaji SureshikaJanuary 16, 2014 at 3:58 AM

    Hi Julien,

    We default ship localization files for english and spanish in WSO2 APIM apps.If you want to provide support for other langauges like french in APIPublisher/Store,you have to customize the apps by adding new localize files to below four locations.

    To localize jaggery file included strings in publisher=>add new locale file for {AM_Homr}/repository/deployment/server/jaggeryapps/publisher/site/conf/locales/jaggery
    To localize jaggery file included strings in store=>add new locale file for {AM_Homr}/repository/deployment/server/jaggeryapps/store/site/conf/locales/jaggery

    To localize javascript file included strings in publisher=>add new locale file for {AM_Homr}/repository/deployment/server/jaggeryapps/publisher/site/conf/locales/js
    To localize javascript file included strings in store=>add new locale file for {AM_Homr}/repository/deployment/server/jaggeryapps/store/site/conf/locales/js

    ReplyDelete
  3. UnknownJune 24, 2016 at 6:33 AM

    Hello! For localization projects, I would recommend using a software localization tool like POEditor.

    ReplyDelete

Post a Comment

Popular posts from this blog

Passing end-user details from client to real backend endpoint via JWT token

In real-world business system,WSO2 API Manager useful on exposing company APIs, in a secured and controlled manner with the features provided by APIManager as; OAuth support [To secure API invocations] Throttling support [To control API invocations] Monitoring support [To track API usage] More technically what happening is when a user sends a particular API request,it will goes to WSO2 APIManager node and from there,the request will route to the real implemented back-end endpoint of the particular API and get back the response and returned it to the API invoked user. There can be a use-case,that this back-end endpoint may expect the details of API invoked user as to pass those details to some internal company usage  as; Additional authentication/authorization Track usage data from an internal system. So how to support above requirement from WSO2 AM. There comes the use of JSON Web Token[JWT] implementation done inside WSO2 AM. JWT is a means of representing claims to...
7 comments
Read more

How to rollback/commit processing messages from WSO2 ESB when enabled JMS transaction

This blog post describes the below use-case where WSO2 ESB 4.6.0 act as the intermediate channel in-between two JMS queues. The Use-case First messages will be de-queue to a proxy service deployed in WSO2 ESB from an queue in ActiveMQ message broker. Then inside ESB,the incoming messages will undergo with some message mediation flow and then the message will be send to another JMS queue deployed in JBoss server. Inside the ESB,following failures could be happen;            a) Failures during message mediation process failure inside ESB [for example if you                use   dbreportmediator/lookup mediator inside mediation flow,some times failures can                happen due  to database connection failures]          b) Message sending failure,due to endpoint is unavailability.[For example,the JBoss  ...
4 comments
Read more

TPP Journey through WSO2 Open Banking

Introduction 2018 is all set to be a game-changing year for European banking. The Revised Payment Services Directive (PSD2) has opened the door to new third party providers [TPPs] to connect with banks and manage finances of bank customers on behalf of them. The PSD2 regulation has mandated banks to expose their core-banking account data and payment services to authorized TPPs to consume. Thus as a bank it’s essential to have a solution which will securely expose their internal banking services to third party providers in a trusted manner. WSO2 Open Banking solution provides all required components to expose bank APIs in a well secured manner in order to become PSD2 compliant. This article explains about the importance of the TPP role in PSD2 domain, the requirements set that banks need to provide for TPPs by PSD2 regulations and how WSO2 Open Banking solution supports these requirements.  From my last blog ,I have given an introduction for PSD2 and WSO2 Open Banking soluti...
4 comments
Read more