-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Rob,

On 4/10/20 13:26, Rob Tompkins wrote:
> Curious…do you deal with bi-directional text ever (i.e. both
> L-to-R and R-to-L variants in the same text block)? Just looking
> over at the java.awt.font.* package and how it manages this.
> Granted, it doesn’t do so using Locale’s (which generally make more
> sense to me).

No current plans to handle bidi text, but I wouldn't want to
necessarily rule it out if I could avoid it.

> I’m curious how cleanly Locale.script maps onto fonts over there
> because they seem to be using fonts to sort out whether something
> is L-to-R or R-to-L.
Hmm. I won't be able to predict the font being used by the browser, of
course.

I have discovered, unfortunately, that Java's "script" field is often
empty even for languages known to be right-to-left, such as "ar"
(Arabic). So I may have to implement my own list of scripts for a
particular language, or at least maybe a default-script given a
particular language. Or simply stick with the naive implementation I
already have where a single language implies ltr/rtl which isn't
perfect but ... perfect may be difficult to achieve.

Thanks,
- -chris

>> On Apr 10, 2020, at 12:43 PM, Christopher Schultz
<[email protected]> wrote:
>>
> All,
>
> This is likely off-topic because this isn't really about any
> particular commons-* project, but I know there are Java-text wonks
> who lurk here, so I figured this was a good place to ask. I'm
> happy to relocate this question elsewhere if there's a better
> forum.
>
> I'd like to know what the best practices are for managing
> text-direction in Java.
>
> It will help to give some background about my project's efforts
> thus far .
>
> We have two kinds of text in our web-based project:
>
> 1. Standard UI text, with replaceable parameters and such, in
> properties files. This text is generated by programmers, etc.
>
> 2. "Content" text, stored in an array of database tables. This text
>  is entered by trained users through an administrative interface.
> There are some 3 dozen tables like this in our database.
>
> We are using Struts 1.x, which has great support not only for
> resource bundles, but also for resolving which resource bundle to
> use when the best one isn't found. For example, I can ask for
> Portuguese and, not finding it, actually discover that I've gotten
> English instead. That's not something that e.g. Servlet API
> provides.
>
> So category 1 above is handled, indirectly, through resource
> bundles, and I can see which java.lang.Locale is represented by
> each.
>
> Category 2 is handled by having a pair of fields in each database
> table (storing text records): language and country. Each is a
> CHAR(2) with the country being nullable. All of the code to move
> the text to/from the database was written by our team using
> java.util.Locale as a basis (ignoring the locale "variant").
>
> [NB: I use separate language and country fields because we need to
>  search for records separately by each of those.]
>
> When looking at how to properly-support right-to-left text such as
>  Arabic, Farsi, Urdu, Hebrew, etc., I discovered that using CSS
> this is very easy from a UI perspective and I've developed some
> simple CSS classes which effectively display the proper
> text-direction AND layout which are appropriate... if I can
> determine the proper text-direction.
>
> My first implementation just had a list of languages ([ar, fa, iw,
>  ...]) that were always right-to-left. Looking up
> Locale.getLanguage() in my RTL-language-list works great, and I
> can set a CSS class in my HTML <body> element to get the
> page-layout and text-direction working as desired.
>
> Then I discovered that the above is all wrong: text-directionality
>  isn't determined by the /language/ but by the language /script/,
> of which there can be some that do, indeed, disagree about
> text-direction. So my list of languages doesn't work in all cases.
> I need something else.
>
> It seems that in the case of Category 1 above, this is simple: I
> can simply create a bundle key called text-direction and let the
> bundle decide. This has the advantage of the person writing the
> localized bundle getting to make the decision as to what the
> text-direction ought to be. I think I can call that problem
> "solved" at this point.
>
> With Category 2, our standard operating procedure is to have a call
>  like this:
>
> public FooClass.Text getFooText(Locale locale);
>
> FooClass.Text looks like:
>
> public Locale getLocale(); public String getText();
>
> This allows us to do:
>
> FooClass.Text text = getFooText(Locale.UK);
> System.out.println(text.getLocale());
>
> And have the output be "en_US" if there is text available for en_US
>  but not for en_UK.
>
> But how to handle the directionality?
>
> Looking at java.util.Locale for (hopefully) some direction confuses
>  me. First of all, Locale historically had 3 items: language,
> country, variation. Language and country I already have. As I
> mentioned previously, we've been ignoring variant. Maybe that will
> get me what I need?
>
> Maybe not.
>
> The javadoc for Locale basically says that variant can be anything.
>  The same javaddoc mentions "script" but then says this about the
> 1-, 2-, and 3-argument constructors:
>
> " These constructors allow you to create a Locale object with
> language, country and variant, but you cannot specify script or
> extensions. "
>
> Okay, so .. what do I do about script?
>
> Maybe I've been failing to keep updated when it comes to the
> features of java.util.Locale over the years. In the Java 1.7 (and
> later) javadoc, I discover that java.util.Locale.Builder exists
> and it CAN specify a script. Also, Locale has a "script" member,
> now, so I can:
>
> Locale loc = Locale.Builder()
> .setLanguage(rs.getString("language"),
> .setCountry(rs.getString("country"),
> .setScript("rs.getString("script")) .build();
>
> String script = loc.getScript();
>
> Now I can grab the R-to-L scripts from the Wikipedia page for ISO
> 15924 and say:
>
> if(rtlScripts.contains(loc.getScript()) { // do the right-to-left
> stuff }
>
> This means that I should be able to accomplish what I'm looking to
> do by :
>
> 1. Adding a new column to all text-tables in my database for the
> nullable "script" code.
>
> 2. Update my code that reads / writes those tables to include the
> "script" in its work.
>
> 3. Consult the locale's "script" attribute combined with my list of
>  R-to-L scripts when determining text-directionality.
>
> Does all that sound about right?
>
> Thanks in advance, -chris
>
>>
>> ---------------------------------------------------------------------
>>
>>
>>
To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>
>
> ---------------------------------------------------------------------
>
>
>
To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6d0IoACgkQHPApP6U8
pFjGIQ/+NvLf76QG8QRtwUuckTgkGr+9jTXJSTBXzRmiFWxUUn5jafVUD5EE7ZoB
CkvgSsVUZOB/ByRtBB13ftJqpv05Auy4jkE3EZ5M2E1bfnnFdY8A9DdwKRkiPl5Y
0b1cQBNeQHABcjK0kuMVfCIf7NAicVDJOkBwelNqVW90PcWVhxy1q2fXrtqcWfkF
jTar3mzEXrSpxGU5i9aBXyG8eA7vDuOUUqQzyvERv95ZcC56skbvubNI5GtbvlrI
wH/OsYzF/ZA2a/Vfmr15PuS6PxEIeXx2ElCzMjZjB+TgYwa5DfMbXf+MtS3pz8QW
4Vqey5PedooHiLvMvmXK4NyCmfkYKa2kWvp3AgRUGM73tuqvOgf2CU9hovk2MnHh
RM2LBWDap69ZBhfZvor3igQ9EulRkWrPfkNW2sMOdcdVSTrwgDXhPuPyRND4nMiE
vdTJtG7ZAHEdTNgUgFYcadNMPgoybKSoZg5Od1YLPqE90QzBzdXLjtn+rjOtyh5J
pSlHYg2uqiN07z2n3kgKr9TrGbaOwOPQs4v+gonveSagtzUL0xbU5Qu+/jvZn8WZ
PADL9XrebYiDkc0jkTqu2HPcOBXfcKeoW8+3DiO8TA46VpLA4KDXNYMwn/lqHh3u
gmIQZbewAnbyNIsHa/CXF2Zk3DTvRdxdIXZGDBca7Yjpp8KzZww=
=xJRI
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to