RTL support

[mwmw7]

Edited by Globalize team:

Requirements:

• RTL data available on JSON CLDR? http://unicode.org/cldr/trac/ticket/9038

TODO:

• API
  
  What can Globalize do with that information. CLDR contains a lot of information, Globalize is all about formatting and parsing, not wrapping everything that CLDR provides. So assuming CLDR actually exposes the RTL boolean in the JSON packages, what could Globalize do with that?

---

Is there feature for RTL in globalize?

i have checked a text file for RTL in CLDR data (core/common/properties/scriptMetadata.txt)

and if we convert it to json format than we could support RTL

scriptMetaData.json
[
  {
    "IDENTIFIER":"Zyyy",
    "RANK":1,
    "RTL":"UNKNOWN"
  },
  {
    "IDENTIFIER":"Latn",
    "RANK":2,
    "RTL":"NO"
...
]

function isRTL(locale){
 var local = Globalize.locale().attributes.script,
       result = null;
        if(scriptMetaData){ // -> defined some where in the first place
            scriptMetaData.forEach(function(item){
                if(item.IDENTIFIER === local){
                    switch(item.RTL){
                        case 'YES':
                            result = true;
                            break;
                       case 'NO':
                            result = false;
                            break;
                       case 'UNKNOWN':
                            result = true;
                            break;
                    }
            return;
      }
    });
return result;
}

reference
http://www.unicode.org/Public/cldr/26.0.1/core.zip
https://github.com/enyojs/enyo-ilib/blob/master/ilib/locale/scripts.json

[rxaviers]

Please, what's the use case of this information?

PS: For some reason BIDI is not available on JSON CLDR. For the record, useful links http://unicode.org/reports/tr9/, and http://blog.scottlogic.com/2015/02/13/rtl.html.

[mwmw7]

For example ( like this Interactive demo -> #420 )

1. User select local by clicking in select menu
2. Globalize sets local
3. User wants to know that the selected local's direction (rtl or ltr) to change UX for RTL style

this is use case of this information
and of course i know BIDI is not available on "JSON" CLDR
but this feature is very very useful

[tomerm]

Similar functionality was introduced into ICU some time ago. Please see following ticket: http://bugs.icu-project.org/trac/ticket/10736
Knowing natural text direction for given language / locale programmatically is essential for handling formatting issues. Imagine translatable message with placeholder(s):
Table {0} does not exist in {1} database
Obviously this message can be translated to many languages. Moreover, language of placeholder is not known in advance. We can have English message (as above) with Arabic and Chinese data replacing the placeholders. To assure proper layout of the message we must know natural text direction of language (in which message currently appear on the screen).
We can obviously hold an array / data structure which includes this info for all languages. But if we can do it in a standardized way it is much better. Please observe that CLDR is a standard repository which already includes this information.

PS. Natural text direction for languages with bidirectional scripts (such as Farsi, Arabic, Hebrew, Yidish etc.) is RTL while for others (i.e. languages based on Latin / Cyrillic scripts), it is LTR.

[jzaefferer]

Getting RTL information into JSON CLDR packages seems like a good idea, for the reasons described above. Is there are CLDR ticket for that? If not, does anyone know why this information isn't in the JSON CLDR package?

Beyond that, I can't tell what Globalize what do with that information. CLDR contains a lot of information, Globalize is all about formatting and parsing, not wrapping everything that CLDR provides. So assuming CLDR actually exposes the RTL boolean in the JSON packages, what could Globalize do with that?

[rxaviers]

@tomerm, Unicode has explicit direction mark, such as U+200E LEFT-TO-RIGHT MARK or U+200F RIGHT-TO-LEFT MARK (more info at http://www.unicode.org/reports/tr35/#Text_Directionality). CLDR data for date or number formats already use this characters for setting correct text direction. Any reason this cannot be used in your use case?

[tomerm]

Indeed Unicode Control Characters (UCC) is the solution for the formatting issues. There are many more UCC which can be used (i.e. LRE, RLE, LRM, RLM etc.). The suggested change for the message formatting mechanism in JQuery can be tracked via #539
However, please observe that we still need to know the information about RTL property (aka natural text direction for given language) in order to understand which UCC to use for formatting. Imagine following example. The message is as follows:
{0} - {1}
Imagine both {0} and {1} are replaced with Arabic characters for example:
ABC - DEF
On the screen they will appear as:
FED - CBA
For English UI (not mirrored UI) the expected display is:
CBA - FED
For Arabic /Hebrew UI (mirrored UI) the expected display is:
FED - ABC
To properly enforce order of tokens in the message (regardless of possible data placeholders may include) we need to know the GUI language and its natural direction (RTL property from CLDR).

Finally regarding usage of UCC in CLDR. From our perspective storage should not include any UCC. This is because UCC are used for display purposes only and thus they should be injected just before the display when rendering engine and its rules are well known. CLDR is a data provider which has nothing in common with rendering. On the CLDR level you never know which rendering engine will be used for text display. Assuming that all rendering engines are UBA (Unicode Bidi Algorithm) compliant and support UCC is unfortunately not a safe assumption at the moment.
Having said that, you are correct that CLDR is one of the examples in which UCC are used for proper display of Bidi text.

[rxaviers]

Similar functionality was introduced into ICU some time ago. Please see following ticket: http://bugs.icu-project.org/trac/ticket/10736

In the issue, I didn't find how API was changed to address it. Please, could you point me to it? Basically, I'm interested to know How can we help?

[tomerm]

I think we mix two discussions. This specific one is about making RTL information available. As simple as that. NOT about how it is going to be used inside JQuery or JQuery based code.
http://bugs.icu-project.org/trac/ticket/10736 is also about how to make RTL information pro-grammatically available. You should not look for any use cases on how this information can be helpful in that ICU ticket.
RTL information simply says that for English natural direction is LTR, while for Arabic it is RTL.
We are not trying to solve any issues yet by making RTL information available.

On the use case when RTL information can be useful we should look at #539 ticket. So, if you wish to continue the discussion on UCC I suggest to do it in that latter ticket.

What do you mean by "How can we help ?" Who are "we" ? JQuery code ?
I think it is should be pretty clear from #539 ticket.

If I still misunderstand your question(s) I would appreciate if you can rephrase them. Appreciate your help in advance.

[rxaviers]

This issue has a wide scope, it's about RTL support in Globalize in general.

Basically, @jzaefferer's questions above summarize what needs to be discussed here. One is about the feasibility of this feature (i.e., RTL info needs to be available in JSON CLDR). The other is about defining what actually Globalize could do with it, which could have its definitions helped by taking into account the second discussion you and @ashensis brought up.

Let's discuss the details of the second discussion at #539 and we bring the results here.

PS:

how it is going to be used inside JQuery or JQuery based code

I suppose you are using the term jQuery to refer to Globalize. But, note this project has no code relationship or dependency with jQuery (the project). I want to make sure this is clear.

What do you mean by "How can we help ?" Who are "we" ? JQuery code ?

I mean: "What do you expect from Globalize to help you with your needs?" Just let me know if this is confusing.

I think it is should be pretty clear from #539 ticket.

Considering you make @ashensis's your suggestion... That works for me.

[tomerm]

RTL information will be available via CLDR JSON. The associated ticket: http://unicode.org/cldr/trac/ticket/9038 was accepted. I will keep watching that ticket for the target date / time line.

[rxaviers]

Excellent. I've updated issue description accordingly.

[unindented]

@rxaviers looks like their ticket was fixed a while ago. How can I consume this info from Globalize?

[rxaviers]

@unindented you can access the CLDR info itself, an example by using cldr-data package:

npm install cldr-data

// https://github.com/unicode-cldr/cldr-core/blob/master/scriptMetadata.json
var scriptMetadata = require('cldr-data/scriptMetadata');
// > {...}

Please, just let me know if you have any question.

[rxaviers]

I belive the answer to the question below is nothing, therefore we can go ahead and close this issue. If anyone thinks differently, please just let me know.

What can Globalize do with that information. CLDR contains a lot of information, Globalize is all about formatting and parsing, not wrapping everything that CLDR provides. So assuming CLDR actually exposes the RTL boolean in the JSON packages, what could Globalize do with that?