-
Notifications
You must be signed in to change notification settings - Fork 603
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RTL support #423
Comments
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. |
For example ( like this Interactive demo -> #420 )
this is use case of this information |
Similar functionality was introduced into ICU some time ago. Please see following ticket: http://bugs.icu-project.org/trac/ticket/10736 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. |
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? |
@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? |
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 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. |
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? |
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. 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 ? If I still misunderstand your question(s) I would appreciate if you can rephrase them. Appreciate your help in advance. |
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:
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.
I mean: "What do you expect from Globalize to help you with your needs?" Just let me know if this is confusing.
Considering you make @ashensis's your suggestion... That works for me. |
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. |
Excellent. I've updated issue description accordingly. |
@rxaviers looks like their ticket was fixed a while ago. How can I consume this info from Globalize? |
@unindented you can access the CLDR info itself, an example by using
// 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. |
I belive the answer to the question below is
|
Edited by Globalize team:
Requirements:
TODO:
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
reference
http://www.unicode.org/Public/cldr/26.0.1/core.zip
https://github.com/enyojs/enyo-ilib/blob/master/ilib/locale/scripts.json
The text was updated successfully, but these errors were encountered: