You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
--
When the article inserts ALM at the start of a numeric string, it does so because it knows that the language is Arabic (and, importantly, not Persian, which uses the same script). Of course the application also needs to know that this is a range, expression or numeric date.
For the other remaining difficulty after isolation has been applied (ie. the titles that start with 'CSS' but should have a base direction of RTL), could we also solve the problem if we know that these strings are arabic, persian and hebrew, and that therefore the expected base direction would be RTL?
Note that sometimes the script subtag may be important eg. az-Cyrl, other times not.
--
It would fail if you tried to apply the base direction based on the language of the surrounding context, ie. the direction of the card in the examples, ie. if you surrounded the inserted strings with not just , but because the language of the card is Arabic.
Although this would fix the problems with the translated titles in RTL scripts, which isolation alone doesn't, it breaks the japanese and english titles by pushing the exclamation mark to the left.
Note that the exclamation mark at the end sounds trivial, but it also represents what happens with examples such as "The book مغامرة جديدة is good.", where 'the book' and 'is good' get swapped over (not good).
--
I think it works, however, by looking at the language of each individual string, and setting the direction of the element (or equivalent) on that basis, maybe that would be better. (However, how often can you expect to have that information available?)
As long as the english title is labelled as 'en' and the arabic title as 'ar', that should produce the right result, eg. we may be able to use something like the JSON-LD format without adding direction metadata(?)
A problem with this approach is that it requires the application to consult a lookup table to determine which direction to apply for each string as it is inserted.
The text was updated successfully, but these errors were encountered:
And overlooking the fact that e.g. the lang attribute doesn't affect how HTML renders the string, while the dir attribute does. That is, it may be helpful to glance at language metadata when direction metadata is not present (as a kind of fallback), but it doesn't necessarily solve the problem.
There are some excellent examples in the above comment. I think we should point out the "The book ... is good" problem. More thought needed here. Suggest text?
This issue uses examples at https://w3c.github.io/i18n-drafts/articles/strings-and-bidi/index.en
The ideas are not particularly coherent yet (apologies).
--
When the article inserts ALM at the start of a numeric string, it does so because it knows that the language is Arabic (and, importantly, not Persian, which uses the same script). Of course the application also needs to know that this is a range, expression or numeric date.
For the other remaining difficulty after isolation has been applied (ie. the titles that start with 'CSS' but should have a base direction of RTL), could we also solve the problem if we know that these strings are arabic, persian and hebrew, and that therefore the expected base direction would be RTL?
Note that sometimes the script subtag may be important eg. az-Cyrl, other times not.
--
It would fail if you tried to apply the base direction based on the language of the surrounding context, ie. the direction of the card in the examples, ie. if you surrounded the inserted strings with not just , but because the language of the card is Arabic.
Although this would fix the problems with the translated titles in RTL scripts, which isolation alone doesn't, it breaks the japanese and english titles by pushing the exclamation mark to the left.
Note that the exclamation mark at the end sounds trivial, but it also represents what happens with examples such as "The book مغامرة جديدة is good.", where 'the book' and 'is good' get swapped over (not good).
--
I think it works, however, by looking at the language of each individual string, and setting the direction of the element (or equivalent) on that basis, maybe that would be better. (However, how often can you expect to have that information available?)
As long as the english title is labelled as 'en' and the arabic title as 'ar', that should produce the right result, eg. we may be able to use something like the JSON-LD format without adding direction metadata(?)
A problem with this approach is that it requires the application to consult a lookup table to determine which direction to apply for each string as it is inserted.
The text was updated successfully, but these errors were encountered: