Localization and internationalization framework

[enchev]

Localization and internationalization framework

[sam0829]

Any update on supporting RTL? We need this support for our application. without this, we can't surely go ahead with NativeScript.

[aboalwi]

@valentinstoychev Umm sorry i wasn't clear enough.. I mean RTL direction in layout. and the ability to change it any time. pretty important can't live without it.

[valentinstoychev]

Please check this solution for i18n by Dan Tamas:
https://www.nativescript.org/blog/i18n-internationalization-support-for-different-languages-in-nativescript

[OPADA-Eng]

Any news about this ?

[jalchr]

Hi @AntonioCuevaUrraco, great work.
Any specific release dates or this is only available in the development branch ?
Is there any RTL/ LTR support built into NativeScript.

Thanks and again great work.

[hemedani]

Hi @valentinstoychev
The i18n plugins did not handle the rtl version for right to left language with i18n: bi-directional ...

[stephenfeather]

Couple of thoughts. Using strings.xml, one of the targetted platforms resources files are already done for us. It requires building localized resources files for iOS. I'd also add, that there are a number of online sites that are setup to assist in the translation of strings.xml.

If a json format is used, then native resources for both platforms need to be generated. Why use native resources? Because these are used by the app managers for things like app names, or in settings screens, things that are not being controlled by the js engines. Using a custom json format would negate the value of existing translation tools.

i18n support is also much more than just strings, but as mentioned includes images, videos and other resources. Funny as it seems, android is probably the easiest native platform to handle all this in. Sort them out by folders and 'it just works' (are you allowed to say that regarding android?). iOS requires sub projects and asset containers and witchcraft.

@alejonext approach of a simple L('resourceTag') for strings works for me, module may need some fallback features. I know this, use this regularly, and its second nature.

That being said, I have code used to swap strings 'on the fly' meaning, load a language into an app regardless the language set in the system. So you could have english (en) system but force the app to display in spanish (en). Was used to swap documents and pamphlets between 4 languages. In that case, we used JSON resources files.

But lets get this topic back up and running.

[enchev]

The easiest way will be to create a view-model with desired properties, get localized properties values from resources:
http://developer.android.com/guide/topics/resources/localization.html
http://www.raywenderlich.com/64401/internationalization-tutorial-for-ios-2014
and bind your UI components to the view-model properties.

[jamlfy]

Well... I create a module for Native, well use the strings natives. look

[vakrilov]

As a part of the this task we can add support for loading different files based on the language similar to the resolution specific views.
For example loading one of the following files based on the language:

• strings.lang-en.json - English language
• strings.lang-fr.json - French language
• strings.json - default language

[jamlfy]

@vakrilov Very interesting! in fact it is much easier than the way I propose.

[RangerMauve]

I like the proposed solution, @vakrilov . Is there any chance that this would affect performance adversely?

[ligaz]

Something to look into as well is the globalize library part of jQuery foundation: https://github.com/jquery/globalize

[danicomas]

@vakrilov @enchev Are you saying that it will be added in the NativeScript core or different module? And other question. What do you think that it will be available? Next Version? Regards.
+1

[jlooper]

+1 for localization, keeping an eye on this one

[sitefinitysteve]

I need to be able to pull in and set the resource labels on load as well (from remote source, not static in the app)...hope the API can accomodate

[TobiasHennig]

I know this is in progress, but can someone help me to get strings from an strings.xml in Android.

I try application.android.context.getResources().getString("app_name"), but it doesn't work and quiet with an android.content.res.Resources$NotFoundException.

I think it is not possible to pass an string as an resource key, but how do i express R.string.app_name in NativeScript?

[jamlfy]

Well... My module, thats take look. Bat vakrilov, say thats cool!

[TobiasHennig]

I had a look at your module before and had the same issue that i described.

[NathanaelA]

Hmm, interesting; I actually have a simple plugin I made that is something similar to @vakrilov suggested where it uses a language.en.js or language.ru.js file to pull in the required resources.
So for example my language.en.js has

exports = {
   main-screen: {'L_HELLO': "Hello", 'L_BLAH': "Blah"...},
   about-screen: {'L_ABOUT': ...}
};

However, it is very simple system and doesn't support things like "0 items" "1 item" "2 items". (notice the missing "s" in 1 item) So my text has to be "x item(s)". I haven't decided how (or if) I want to support that. There is a lot to translating; but at this point the simplicity to be able to get things going it is what I need.

However, one thing that I do do is monkey patch the builder system to have it automatically replace all Declarative UI screens "L_*" with the text in the language.JS file while it is generating the ui. This makes it something I can require in the app.js file and forget for the most part it is their...
So my DCUI look like

<Label text="L_HELLO"/>
<ActionBar title="L_BLAH"/>

[AntonioCuevaUrraco]

+1 for this one, we are trying to get the multi language in our app. We tried already to use the plugin with no success...

[jalal]

+1 please. we only need two languages at present so may just go with two apps, but it would be neat to have one app, many languages/locales.

[AntonioCuevaUrraco]

We are adding French support to our app soon, our approach to get it going before NS support is like this:

As soon as possible on your app load the language

//Get node modules data
var Jed = require('jed');
var lang = platformModule.device.language;
lang = lang.substring(0, 2);


global.sprintf = /*require("sprintf-js")*/Jed.sprintf
function loadI18n(lc) {
  var lcobj = {}
  try {
//this is the path to your json file with the language strings 
//use po2json to have something readable  
    lcobj = require("./Localization/" + lc + "/" + lc + ".json");
  } catch (e) {
    if (lc) {
      console.warn(lc + " not found, using default")
    } else {
      console.warn("using default")
    }
  }
  var i18n = new Jed(lcobj);
  global._ = function(arg1) {
    return i18n.gettext(arg1);
  }
};

loadI18n(lang);

Then later on you have to change all the xml strings to use the bindingcontext

      <Label text="{{ Log in }}" />

and on the code

export function pageLoaded(args: EventData) {
  var page: Page = <any>args.object;

  page.bindingContext = source;

  //Localization
  source.set("Log in", sprintf(_("Log in")));
}

Take into account that you will have to change all the xml plain text to be set programmatically

@AntonioCuevaUrraco isn't it loading all the text right in the memory or it executes a open/read file routine on every check?

Beside that i would like to share my thoughts about a possible pattern, but as i'm not a iOS i will focus on android only :/

• The string itself should be defined on a i18n.json i think. Like android already does it should receive a label as index

{
    "main_window_title": {
        "default": "Main Title",
        "fr": "Titre Principal",
    }
}

Ok. This file should be translated (for android) to the native valeus/strings.xml format :)

• default language as english res/values/strings.xml

<resources>
   <string name="main_window_title">Main Title</string>
</resources>

• French res/values-fr/strings.xml

<resources>
   <string name="main_window_title">Titre Principal</string>
</resources>

• But why holding tight to the current native pattern?

Based on the affirmative that nativescript is actually generating native .xml layout we can make use of this right over the current text attribute. So a nativescript button <Button text="@string/main_window_title" /> will work flawlessly. Like no need to extra parsing :3

• Ok, but we want support for multiple platforms

This (maybe) could be achieved by using one of this two extra syntax <Button text="i18n/main_window_title" /> ?

As i try to highlight before, i don't have experience on this topic with iOS but i think half of this pattern would be nice :)

[AntonioCuevaUrraco]

@jalchr This is our personal implementation for localization using some standard javascript libraries. I think the guys of NS can answer you better about when NS will start to provide localization.
@vyscond we used this approach because jed is already a solid think and takes care of a lot of things, we didn't want to make everything from 0.
Also to create a .po file and use some of the editors freely available is easier for the translators to do their job and there is tools that can create a .json from the .po
I am not an expert in localization so I have some questions for you or whoever knows.

• What is the advantages of creating the i18n.json and how do you ask the translators to edit it?
• do they have to make it manually?
• what about several translators working in different languages can two i18n.json files be merged?

I think the
<Button text="@string/main_window_title" />looks great, I was thinking to use something like that and modify the node modules to return a translation even if that property is not found in the binding context but It was really deep in the core and it would take a good while to make it and don't break something else. As a final thing I think we should use the native localization on the background somehow

• What is the advantages of creating the i18n.json and how do you ask the translators to edit it?

The format is not really the point here. The goals is make an agnostic platform way to express this division between the strings. The .json format was intent to make it easier to read through node. But i would strongly agree if they choose a more human way like a .yml.

• do they have to make it manually?

Yes or no. With this "loose" separated file it could be build a external app to update/edit thing? I don't know. Right know i didn't need to translate my apps for more than 2 languages (native and english) so i never need external people to do that :/

I can't really understand the concern about gathering this kind of work from a "translator" and merging it.

• what about several translators working in different languages can two i18n.json files be merged?

Good point. On this way we could think on make the i18n a directory with sub-directories with the names using the global pattern e.g.: en_US, pt_BR. This could avoid all things related to merging procedures :)

My base concern was just to know with your method is using too much memory from the too little with have on most of the devices and the second is about apply the same design/idea of the native script which is try to "translate" every possible routine to native handling lib/routines :)

[AntonioCuevaUrraco]

@vakrilov I understand your concern about memory and yes the method var i18n = new Jed(lcobj); is creating an object with all the key-values so that is probably loading the heap.

But I have been checking with the device monitor and I can't see a difference before creating the object and after so I am not sure it is really bad. Maybe we have an android heap guru to answer this because I have been working enough already to know that thing is really really complex

@AntonioCuevaUrraco i see. A guru about that would be really nice and insightful. I can even be sure how android actually use the .xml files itself.

[hemedani]

for first step please support direction css property in framework
tanx

[YuvApps]

Hi @valentinstoychev
Can you give me the full list of the supported languagesin the i18n npm solution? Because only es (Espanol) Works for me.. as your example.
Thanks

[ryc16]

Hi,

I believe multiple screen based on language is not defined and implemented at currently release. I wonder is there any way to specify code behind file manually to be used for time being? So if I have following.

page2.xml
page2.en_US.xml
page2.fr.xml
page2.ts

No matter which language xml file is loaded, I still could use page2.ts as code behind.

[aboalwi]

Please add this feature asap or at least provider some 'basic' guide for it. I really need it in every app i'll ever gonna make here.

[valentinstoychev]

@aboalwi which feature exactly you refer to? What functionality are you missing from the i18n plugin?

[spstratis]

@valentinstoychev I'm also curious about what @aboalwi is mentioning. Is there anything currently in Nativescript that supports UIs that need to display RTL such as Arabic?

[Habeeb-mohamed]

@valentinstoychev RTL is working partially almost 90% in iOS. but in android it is moving from right to Left in action bar. Is there a work around to achive this

    <ActionBar title="{{'Contactus' | L}}">
        <NavigationButton android.systemIcon="ic_menu_back" (tap)="goBack()"></NavigationButton>
        <ActionItem ios.systemIcon="0" android.systemIcon="ic_menu_send" ios.position="right" (tap)="Submit()" [disabled]="contactUsData==contactUsDataOld"></ActionItem>
    </ActionBar>

[vakrilov]

We haven't plan anything particular around this feature for the upcoming 4.0 release.

[NickIliev]

Update regarding the i18 support.

At this very moment, the localization in NativeScript Core projects is supported via a great community driven plugin called nativescript-localize. The plugin provides all must-have features for localization and can be used in Core and Angular based projects.

Based on the above, we are not currently planning to implement the i18n directly into the Core framework and the team recommendation is to use the available plugin in your projects.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.