-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6QoisACgkQHPApP6U8
pFgVnw/+JaTQZLr8aJPTXPFNQzfrnBZ7uaa/FKIezVCu2dMZrFEk/Ea00LUl+yCP
2pQdPgFQqnaIC+pC9/GEdxgsyXZW3liQDl6orKzzLUEF52wRbJL7eA4PEEmpa5bd
eqwi5Kv6rTlIm8/J2unNtdA9NQA87Yk2UskVLOmfO3dvs/0UbTe8YBLsqLt9Y01Z
qprn9109dHlHA/Dyx01ocrJpXtRyoMiqZNxuq0UVWWtTeSPYLHgnDCoTzs9HLqxB
SDqtld4xH1LZggUBMphXzRYL7YMhv7kBO5Z9SBpX9e+KYpZga8dSkx82WHx6Itv2
nBkNRsOHNFM+TDqgmBU640VaVm/z9L0Bb1PDe+a0TVQEo/S6T8isNbaDH/yuEgxm
dL4LtIzVVCVPWBOq6JVW3S0Rdcm1jRjlLJzoCmJpiKA6zWa5O1IIHlFFXrkiVPgi
Kz0oIl9oPcOyxVrIMNJMBt0qd0wfNvPqkLWyeym1tlcajpM3cpPFG4mDpMo8rzbE
+4NQi5UyJdEIdg5MINO6v11yjmY1nw/3HgdMlgdMb33MqDN9Yn7GBsNk5WfmNax0
Fm1vRnps1S5CpJygnrVE7/we0gytEQXoINCPpUJJyZi5YGD1dKUk3QvQ6+iEsasi
cu5izA28BwLaxgV7B941qYYH3u642fuqYgK8w/O8OhSChAcQ/3c=
=Yg7z
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
