Design Questions about static factory classes
Rhino
particularly the classes that are static factories, I've developed some
confusion about localization. Basically, I'm trying to figure out when I
want to have separate constructor and getInstance() methods
First, I hope we can all agree that, in an ideal world, every class which
can produce text output - even if no text is produced per se, most
classed would be capable of producing error messages for Exceptions -
should be written so that it can produce that output in the languages of
the users of those classes. So, if your utility classes are used in
French-speaking countries, text output and/or error messages will be in
French and so forth for other languages. Now, I know that many developers
will not worry about that - after all, the whole IT field seems to be
fairly English-centric - but I aspire to make all of _my_ classes locale-
sensitive.
Now, with the preamble out of the way, let's get down to brass tacks.
Let's say that I want to make a static factory class locale-sensitive but
I don't want to force the user to choose an explicit locale every time
they try to use the class. That suggests to me that I go one of two ways:
1. Provide two private constructors - one that takes a specified locale
and one that uses the default locale - and two corresponding public
getInstance() methods, one of which takes a specified locale and one that
uses the default locale. Then, if the user is comfortable with the
default locale, they use the constructor that doesn't have a locale
parameter, otherwise, they use the constructor that has a locale
parameter and specify the locale of their choice.
2. Provide a single private constructor that has no locale parameter and
a corresponding public getInstance() method. Also provide getLocale() and
setLocale() methods so that a user can instantiate with the single
getInstance() method and then use setLocale() to alter that locale if it
is not to his liking.
I thought I'd have a look at the Java API and see what happens there. I
got something of a mixed bag. A handful of classes have getInstance()
methods that take a Locale parameter, suggesting that they favour
Approach 1. A handful of classes have setLocale() methods, suggesting
that they favour Approach 2. However, the vast, vast majority of the
classes have neither suggesting that they are NOT locale-sensitive and
have no capability for changing the Locale at all.
So I thought I'd ask the learned people on this group for their thoughts
on which approach they'd take when building classes that are meant to be
locale-sensitive. I'm sure there are variations on the two approaches
I've enumerated so I'm open to "none of the above" answers :-)
Personally, I'm leaning towards Approach 2. Approach 1 requires doubling
up of constructors and getInstance() methods and makes you reinstantiate
the class if you want to change Locales. Approach 2 avoids those extra
constructors and getInstance() methods and lets you change Locale by
simply doing setLocale(). There may be negative aspects to that which
aren't occuring to me though so I hope you will point those out if you
see them.
--
Rhino
Tom Anderson
> First, I hope we can all agree that, in an ideal world, every class
> which can produce text output - even if no text is produced per se, most
> classed would be capable of producing error messages for Exceptions -
> should be written so that it can produce that output in the languages of
> the users of those classes.
I strongly disagree. Text for the consumption of end-users should be
localised; text for the consumption of programmers and sysops should not
be. I think the advantages of having a common language for these things
outweight the disadvantages of most people not having them in their first
language. It's like air traffic control - it's vital for clear
communication that i can say "i'm getting the NoMoreJam error", and not
draw a complete blank with French acquaintances who've only ever seen
NYAPlusDeConfiture and Americans familiar with NoMoreJelly. Having a
single language makes googling with error messages and so on a lot more
productive, too - and that's a benefit to the speakers of minor languages,
who have access to squillions of English search results.
Of course, being a native english speaker, i would say that, wouldn't it?
> Let's say that I want to make a static factory class locale-sensitive
> but I don't want to force the user to choose an explicit locale every
> time they try to use the class. That suggests to me that I go one of two
> ways:
Look up 'resource bundles'. They're the standard way of producing
localised messages, and are absolutely what you should use here if you
really want to do this. They use the current locale, so they leave the
onus of setting that correctly on your developers - but they only need to
set it once for the whole VM, and then messages everywhere come out in the
right language. And those who see the world my way and don't want
localised messages can set it to the canonical standard locale - en_GB.
tom
--
If goods don't cross borders, troops will. -- Fr
Rhino
news:alpine.DEB.1.10.1...@urchin.earth.li:
> On Fri, 21 May 2010, Rhino wrote:
>
>> First, I hope we can all agree that, in an ideal world, every class
>> which can produce text output - even if no text is produced per se,
>> most classed would be capable of producing error messages for
>> Exceptions - should be written so that it can produce that output in
>> the languages of the users of those classes.
>
> I strongly disagree. Text for the consumption of end-users should be
> localised; text for the consumption of programmers and sysops should
> not be. I think the advantages of having a common language for these
> things outweight the disadvantages of most people not having them in
> their first language. It's like air traffic control - it's vital for
> clear communication that i can say "i'm getting the NoMoreJam error",
> and not draw a complete blank with French acquaintances who've only
> ever seen NYAPlusDeConfiture and Americans familiar with NoMoreJelly.
> Having a single language makes googling with error messages and so on
> a lot more productive, too - and that's a benefit to the speakers of
> minor languages, who have access to squillions of English search
> results.
>
You raise VERY good points which I totally failed to consider. That is a
great example of how this newsgroup serves as a valuable sanity check on
my thinking.
I was really thinking primarily of messages that end-users, not system
administrators, would see and was trying to accomodate the end-users. I
failed to allow for the system administrators.
So is there a middle ground that would accomodate both groups? Generating
a message in one language for the end-user and a different language for
the system administrator, perhaps in the logs? Hmmm, this needs some
thought....
> Of course, being a native english speaker, i would say that, wouldn't
> it?
>
Hey, we all have our biases and preferences; nothing wrong with that as
long as we are aware of them :-)
>> Let's say that I want to make a static factory class locale-sensitive
>> but I don't want to force the user to choose an explicit locale every
>> time they try to use the class. That suggests to me that I go one of
>> two ways:
>
> Look up 'resource bundles'. They're the standard way of producing
> localised messages, and are absolutely what you should use here if you
> really want to do this. They use the current locale, so they leave the
> onus of setting that correctly on your developers - but they only need
> to set it once for the whole VM, and then messages everywhere come out
> in the right language. And those who see the world my way and don't
> want localised messages can set it to the canonical standard locale -
> en_GB.
>
Sorry, I though it en_US was the canonical standard ;-) I say that as a
Canadian, just to show that I'm not trying to push my own variant of
English :-)
I'm very familiar with resource bundles at a detail; I use them quite
frequently. I'm not quite clear on the "big picture" though. I lack any
significant real-world experience with how "multilingual" systems are
written with Java. For instance, if I were a developer whose native
language was French would I typically install a French-language JVM, read
the Java API in French, and write my system so that it never chose or
changed Locales? Would my classes simply make use of the Resource
Bundles I had written in French and would I leave it up to foreign
purchasers of my system to simply translate the ResourceBundles for their
own languages?
Also, is there much need for systems in which the user can switch
languages on the fly? In other words, let's say I'm working in a system
that uses French language ResourceBundles but am finding that the French
is not to my liking - maybe it's Quebecois instead of Parisian - and I
realize that I will understand better in my second language, English,
which I learned by watching MTV. Would a system typically have the
capability of letting the user invoke a switch to another language via
setLocale()? Or would I install an English-language JVM and run my system
on that?
Hold on, that doesn't quite make sense. I don't recall any language
selection option any time I've installed Java. The language of the JVM
comes from a system property which I can presumably change. Hmm, I wonder
if I should take a minute and switch my language to see what kind of
output I get from core Java classes. Will the message that comes with my
Exception be in the newly-chosen language?.... I should answer this
question for myself with a bit of experimentation....
Thanks for helping me get back on the right track!
--
Rhino
Lew
> Let's say that I want to make a static factory class locale-sensitive but
> I don't want to force the user to choose an explicit locale every time
> they try to use the class. That suggests to me that I go one of two ways:
>
> 1. Provide two private constructors - one that takes a specified locale
> and one that uses the default locale - and two corresponding public
> getInstance() methods, one of which takes a specified locale and one that
> uses the default locale. Then, if the user is comfortable with the
> default locale, they use the constructor that doesn't have a locale
> parameter, otherwise, they use the constructor that has a locale
> parameter and specify the locale of their choice.
Why do you want to provide factory classes at all?
> 2. Provide a single private constructor that has no locale parameter and
> a corresponding public getInstance() method. Also provide getLocale() and
> setLocale() methods so that a user can instantiate with the single
> getInstance() method and then use setLocale() to alter that locale if it
> is not to his liking.
This can be a good solution but can exacerbate concurrency issues.
Generally, not always but generally one should prefer class instances to be
immutable - everything is fixed in the constructor and assigned to final
member variables, and guarded against changes in the internal state of
referenced objects.
Such objects are inherently thread safe.
Even in a single-threaded context, the object that takes a read-only Locale at
construction never risks being used with a different Locale than expected.
Once you make the Locale (or any other attribute) mutable, you have to add
complexity to guarantee that the attribute has a suitable value at any given
time, lest it change between accesses.
For example, collections class instances with an active iterator will throw a
'ConcurrentModificationException' if the collection state changes during the
iteration. This can happen in single-threaded or multi-threaded contexts. In
addition to the complexity in the collection class of checking for and
throwing the exception, there is complexity in the client code of preventing
and/or checking for the exception. Or failing to do so and having a sudden
program crash.
You have to weigh the advantages of having an object whose Locale (or any
other attribute) is fixed at construction for the lifetime of the object,
versus the advantages of permitting an object to alter its state, and perhaps
to live longer. There are also disadvantages to both approaches. (For
example, long-lived objects can put more strain on the garbage-collection
mechanism.)
As for letting "a user ... alter that locale", it's not the user who alters
the locale, it's the code in response to a user action. You could just as
easily instantiate a new object with a different locale in response to a user
action as mutate an existing object.
In your particular case, I'd lay dollars to doughnuts that an immutable Locale
attribute is the better solution.
--
Lew
Lew
> Why do you want to provide factory classes at all?
Oops. I mean "factory methods".
--
Lew
Arne Vajhøj
> In the course of developing test cases for some of my classes,
> particularly the classes that are static factories, I've developed some
> confusion about localization. Basically, I'm trying to figure out when I
> want to have separate constructor and getInstance() methods
>
> First, I hope we can all agree that, in an ideal world, every class which
> can produce text output - even if no text is produced per se, most
> classed would be capable of producing error messages for Exceptions -
> should be written so that it can produce that output in the languages of
> the users of those classes. So, if your utility classes are used in
> French-speaking countries, text output and/or error messages will be in
> French and so forth for other languages. Now, I know that many developers
> will not worry about that - after all, the whole IT field seems to be
> fairly English-centric - but I aspire to make all of _my_ classes locale-
> sensitive.
I think you are too ambitious.
Not everything need to be internationalized.
Some forms of output are not even possible to internationalize
(especially languages outside of the western countries can
be difficult).
You should focus on the output that is rich (looks good, has
advanced capabilities).
GUI's (both fat client and web) plus print intended for
advanced printers (not line printers).
Drop it for console IO, log files, print for line printers etc..
> Let's say that I want to make a static factory class locale-sensitive but
> I don't want to force the user to choose an explicit locale every time
> they try to use the class. That suggests to me that I go one of two ways:
>
> 1. Provide two private constructors - one that takes a specified locale
> and one that uses the default locale - and two corresponding public
> getInstance() methods, one of which takes a specified locale and one that
> uses the default locale. Then, if the user is comfortable with the
> default locale, they use the constructor that doesn't have a locale
> parameter, otherwise, they use the constructor that has a locale
> parameter and specify the locale of their choice.
>
> 2. Provide a single private constructor that has no locale parameter and
> a corresponding public getInstance() method. Also provide getLocale() and
> setLocale() methods so that a user can instantiate with the single
> getInstance() method and then use setLocale() to alter that locale if it
> is not to his liking.
>
> I thought I'd have a look at the Java API and see what happens there. I
> got something of a mixed bag. A handful of classes have getInstance()
> methods that take a Locale parameter, suggesting that they favour
> Approach 1. A handful of classes have setLocale() methods, suggesting
> that they favour Approach 2. However, the vast, vast majority of the
> classes have neither suggesting that they are NOT locale-sensitive and
> have no capability for changing the Locale at all.
I prefer #2 with the note that you set Locale on the factory
not on the objects created by the factory.
Arne
Arne Vajhøj
> On Fri, 21 May 2010, Rhino wrote:
>> First, I hope we can all agree that, in an ideal world, every class
>> which can produce text output - even if no text is produced per se,
>> most classed would be capable of producing error messages for
>> Exceptions - should be written so that it can produce that output in
>> the languages of the users of those classes.
>
> I strongly disagree. Text for the consumption of end-users should be
> localised; text for the consumption of programmers and sysops should not
> be. I think the advantages of having a common language for these things
> outweight the disadvantages of most people not having them in their
> first language. It's like air traffic control - it's vital for clear
> communication that i can say "i'm getting the NoMoreJam error", and not
> draw a complete blank with French acquaintances who've only ever seen
> NYAPlusDeConfiture and Americans familiar with NoMoreJelly. Having a
> single language makes googling with error messages and so on a lot more
> productive, too - and that's a benefit to the speakers of minor
> languages, who have access to squillions of English search results.
I would expect developers, testers and operators to understand
English too, but unfortunately it is not uncommon for customers
to require internationalization for operations. In Europe
both Germany and France often require that. Scandinavia
not so often.
> Of course, being a native english speaker, i would say that, wouldn't it?
The argument for a common language is still valid, but you may have
a problem if the language chosen was french.
>> Let's say that I want to make a static factory class locale-sensitive
>> but I don't want to force the user to choose an explicit locale every
>> time they try to use the class. That suggests to me that I go one of
>> two ways:
>
> Look up 'resource bundles'. They're the standard way of producing
> localised messages, and are absolutely what you should use here if you
> really want to do this. They use the current locale, so they leave the
> onus of setting that correctly on your developers - but they only need
> to set it once for the whole VM, and then messages everywhere come out
> in the right language. And those who see the world my way and don't want
> localised messages can set it to the canonical standard locale - en_GB.
For the text then resource bundles should be the solution, but there
are a lot more to internationalization than just text.
Arne
Arne Vajhøj
>> want localised messages can set it to the canonical standard locale -
>> en_GB.
>>
> Sorry, I though it en_US was the canonical standard ;-) I say that as a
> Canadian, just to show that I'm not trying to push my own variant of
> English :-)
Give the state of US and UK software industry then I think we can say
it is.
And my guess is that Tom meant US English.
> I'm very familiar with resource bundles at a detail; I use them quite
> frequently. I'm not quite clear on the "big picture" though. I lack any
> significant real-world experience with how "multilingual" systems are
> written with Java. For instance, if I were a developer whose native
> language was French would I typically install a French-language JVM, read
> the Java API in French, and write my system so that it never chose or
> changed Locales? Would my classes simply make use of the Resource
> Bundles I had written in French and would I leave it up to foreign
> purchasers of my system to simply translate the ResourceBundles for their
> own languages?
I think it depends a lot of the context you develop software in.
Global or local development?
global => do development in English
local => pick English or local language as you prefer
Are you developing single-customer project-style software or
multi-customer product-style software?
product => internationalize, have English and then add to
supported languages as customers require them (note that
customers can want 3 things A) English version, B) local
version C) Choice of English for local for end users
project => whatever the customer wants
And then we have not even talked about interesting countries
like Belgium and Switzerland with multiple official languages
(Canada is easier because one of the languages is English).
That is not a clear answer, but it is a complex question!
> Also, is there much need for systems in which the user can switch
> languages on the fly? In other words, let's say I'm working in a system
> that uses French language ResourceBundles but am finding that the French
> is not to my liking - maybe it's Quebecois instead of Parisian - and I
> realize that I will understand better in my second language, English,
> which I learned by watching MTV. Would a system typically have the
> capability of letting the user invoke a switch to another language via
> setLocale()?
See above.
Customer is king.
> Or would I install an English-language JVM and run my system
> on that?
> Hold on, that doesn't quite make sense. I don't recall any language
> selection option any time I've installed Java. The language of the JVM
> comes from a system property which I can presumably change. Hmm, I wonder
> if I should take a minute and switch my language to see what kind of
> output I get from core Java classes. Will the message that comes with my
> Exception be in the newly-chosen language?.... I should answer this
> question for myself with a bit of experimentation....
That problem is not so important. You would not want to display
Java exception text to end-users anyway.
Arne
Tom Anderson
> On 21-05-2010 19:16, Rhino wrote:
>> Tom Anderson<tw...@urchin.earth.li> wrote in
> And those who see the world my way and don't
>>> want localised messages can set it to the canonical standard locale -
>>> en_GB.
>>>
>> Sorry, I though it en_US was the canonical standard ;-) I say that as a
>> Canadian, just to show that I'm not trying to push my own variant of
>> English :-)
>
> Give the state of US and UK software industry then I think we can say it
> is.
>
> And my guess is that Tom meant US English.
Certainly not! en_GB is the canonical form, and en_US is merely a popular
but subordinate deviation.
tom
--
They entered the Vortex and the dreams became reality
Tom Anderson
> I'm very familiar with resource bundles at a detail; I use them quite
> frequently. I'm not quite clear on the "big picture" though. I lack any
> significant real-world experience with how "multilingual" systems are
> written with Java. For instance, if I were a developer whose native
> language was French would I typically install a French-language JVM,
> read the Java API in French, and write my system so that it never chose
> or changed Locales? Would my classes simply make use of the Resource
> Bundles I had written in French and would I leave it up to foreign
> purchasers of my system to simply translate the ResourceBundles for
> their own languages?
If you were French, you might.
But in general, i don't think there's any correlation between the
languages of the system and of its developers. A French developer might
well have his machine's locale set to fr_FR, and he might well read
documentation in french (if there is such a thing - i've seen some Sun
documentation translated into japanese, but rarely into European languages
other than english), but he ought to have his JVM set to run in one of the
languages the system is being built for, and he ought to routinely test it
in other such languages.
For instance, i'm currently on a project which will roll out to 23
countries in the first wave. They're all European and North Amererican,
and in a slightly weird twist, to begin with we're only supporting
english, french, and german as languages. So, if you're a native of the
UK, the US, Canada, France, Switzerland, Luxembourg or a few other places,
you have your own language, but if you live in Hungary or the Netherlands,
you'll have to be able to read english, or in some cases in eastern
Europe, german. In the second wave, Korea will be added, and for that,
there will be korean. I assume that in later waves, there will be proper
localisation into national languages, but i haven't heard about that. By
that point, such localisation would not require programmer input (or at
least only a tiny bit) - the client's content management team will be able
to add new locales and their corresponding translations to the system
themselves. We're keeping translations in a database rather than resource
bundle files, so they can do this to a running system without having to
modify the codebase.
Anyway, we're British, the client's programmers are American (well,
they're in America, and are either American or Indian), the contractors we
had involved a while ago were Indian (a mix of hindi, telugu and malayalam
speakers), and the client's HQ, including their infrastructure guys and
the virtual machines where we all work, is in Denmark. We all work in
english. I think the JVM default locale is en_US throughout.
So, a daily feature of our project is an Indian programmer in an office in
the US using a machine in Denmark to look at content in german which will
be shown to customers in the Czech Republic.
I have no idea if any of this answers your question.
> Also, is there much need for systems in which the user can switch
> languages on the fly? In other words, let's say I'm working in a system
> that uses French language ResourceBundles but am finding that the French
> is not to my liking - maybe it's Quebecois instead of Parisian - and I
> realize that I will understand better in my second language, English,
> which I learned by watching MTV. Would a system typically have the
> capability of letting the user invoke a switch to another language via
> setLocale()? Or would I install an English-language JVM and run my
> system on that?
I wouldn't expect to have to install a second JVM. I also wouldn't expect
to be able to change locale on the fly - i might try it, but i wouldn't be
surprised if it didn't work. I would expect that i'd be able to get what i
wanted by killing the system and restarting with the following parameters
added to the java command line (assuming a Sun java):
-Duser.language=en -Duser.country=GB
> Hold on, that doesn't quite make sense. I don't recall any language
> selection option any time I've installed Java. The language of the JVM
> comes from a system property which I can presumably change. Hmm, I
> wonder if I should take a minute and switch my language to see what kind
> of output I get from core Java classes. Will the message that comes with
> my Exception be in the newly-chosen language?.... I should answer this
> question for myself with a bit of experimentation....
Experimentation is often a very good thing to do.
Arne Vajhøj
> On 21-05-2010 16:28, Tom Anderson wrote:
>> On Fri, 21 May 2010, Rhino wrote:
>>> First, I hope we can all agree that, in an ideal world, every class
>>> which can produce text output - even if no text is produced per se,
>>> most classed would be capable of producing error messages for
>>> Exceptions - should be written so that it can produce that output in
>>> the languages of the users of those classes.
>>
>> I strongly disagree. Text for the consumption of end-users should be
>> localised; text for the consumption of programmers and sysops should not
>> be. I think the advantages of having a common language for these things
>> outweight the disadvantages of most people not having them in their
>> first language. It's like air traffic control - it's vital for clear
>> communication that i can say "i'm getting the NoMoreJam error", and not
>> draw a complete blank with French acquaintances who've only ever seen
>> NYAPlusDeConfiture and Americans familiar with NoMoreJelly. Having a
>> single language makes googling with error messages and so on a lot more
>> productive, too - and that's a benefit to the speakers of minor
>> languages, who have access to squillions of English search results.
>
> I would expect developers, testers and operators to understand
> English too, but unfortunately it is not uncommon for customers
> to require internationalization for operations. In Europe
> both Germany and France often require that.
Which can be a bit problematic when having a global team
that needs to fix bugs related to a GUI in German or
French.
Arne
Lew
>> And my guess is that Tom [sic] meant US English.
Tom Anderson wrote:
> Certainly not! en_GB is the canonical form, and en_US is merely a
> popular but subordinate deviation.
It has ever amazed me how well the Brits speak English. Awesome!
--
Lew
Mike Schilling
Some of them even write it well, though rarely as well as the Irish.
Tom Anderson
> Lew wrote:
And of course, it's the Scandinavians who are the real masters of it.
tom
--
The world belongs to the mathematics and engineering. The world is as
it is. -- Luis Filipe Silva vs Babelfish
Mike Schilling
> On Sat, 22 May 2010, Mike Schilling wrote:
>
>> Lew wrote:
>>> Arne Vajh?j wrote:
>>>>> And my guess is that Tom [sic] meant US English.
>>>
>>> Tom Anderson wrote:
>>>> Certainly not! en_GB is the canonical form, and en_US is merely a
>>>> popular but subordinate deviation.
>>>
>>> It has ever amazed me how well the Brits speak English. Awesome!
>>
>> Some of them even write it well, though rarely as well as the Irish.
>
> And of course, it's the Scandinavians who are the real masters of it.
I was thinking of Shaw, Wilde, Joyce, Synge, and Yeats.
Rhino
Yeah, you'd think they invented the language or something ;-)
--
Rhino
Rhino
news:4bf721a5$0$278$1472...@news.sunsite.dk:
It certainly is. I'm trying to write code that will be easily usable by
non-English speakers. But my code isn't actually being written for a
specific customer at this time, other than me. At the moment, I'm trying
to put together a sort of code portfolio. I'm hoping it will show
prospective employers or clients that I am culturally sensitive enough to
write code that will work in multiple languages and knowledgeable on how
to do it. In other words, I don't just want to claim that I am culturally
sensitive but then have no code to back that up. When they challenge me
to prove that I can write code that works for customers in various
locales, I want to be able to point them to some decent examples where I
have done that. I'm just trying to figure out the best way to do that
right now.....
My "code portfolio" is basically a set of classes that generates my
resume in various formats and makes use of various utility classes to do
some of the grunt work. It makes sense to me to internationalize/localize
at least the utility classes to prove that I can do it.
>> Also, is there much need for systems in which the user can switch
>> languages on the fly? In other words, let's say I'm working in a
>> system that uses French language ResourceBundles but am finding that
>> the French is not to my liking - maybe it's Quebecois instead of
>> Parisian - and I realize that I will understand better in my second
>> language, English, which I learned by watching MTV. Would a system
>> typically have the capability of letting the user invoke a switch to
>> another language via setLocale()?
>
> See above.
>
> Customer is king.
Agreed! And if I was writing my code for an actual paying customer, I
would certainly let him/her decide how much i18n they want.
>
>> Or would I install an English-language JVM and run my
>> system
>> on that?
>> Hold on, that doesn't quite make sense. I don't recall any language
>> selection option any time I've installed Java. The language of the
>> JVM comes from a system property which I can presumably change. Hmm,
>> I wonder if I should take a minute and switch my language to see what
>> kind of output I get from core Java classes. Will the message that
>> comes with my Exception be in the newly-chosen language?.... I should
>> answer this question for myself with a bit of experimentation....
>
> That problem is not so important. You would not want to display
> Java exception text to end-users anyway.
>
Really? I find that a surprising thing to say. Maybe we're not talking
about the same thing.
I'm thinking of a situation like completing a form in a GUI. The customer
has to enter his date of birth. Let's say that I can't use a JSpinner for
some reason; it can't do everything I need it to do. The customer is
given a simple JTextField for entering a date. Clearly, the customer
would have many opportunities to enter bad data. He could type in 1985-
15-31 when he meant to type 1985-05-01; the first value is obviously a
bad date since there are only 12 months in the year, not 15. My practice
is to write edits that check for that kind of mistake and generate an
exception, typically IllegalArgumentException, with a clear error message
that reminds the user that there is no such month as '15'. Naturally, the
customer might not be an English speaker so I put all such messages in
ResourceBundles so that other bundles can easily be added for any
languages that I support.
How would you handle such a situation?
--
Rhino
Rhino
> On Fri, 21 May 2010, Rhino wrote:
Sorry for the off-topic digression but I just can't help but admit to
some surprise that some eastern Europeans still know German. Stalin and
his eastern European brothers were pretty ruthless about exiling or
killing their German residents in the immediate aftermath of WW II. I had
thought the German language was pretty much non-existent in the former
Warsaw Pact area by this point.... Based on what you're saying, it
appears that I was premature in assuming an absence of German in those
countries.
> In the second wave, Korea
> will be added, and for that, there will be korean. I assume that in
> later waves, there will be proper localisation into national
> languages, but i haven't heard about that. By that point, such
> localisation would not require programmer input (or at least only a
> tiny bit) - the client's content management team will be able to add
> new locales and their corresponding translations to the system
> themselves. We're keeping translations in a database rather than
> resource bundle files, so they can do this to a running system without
> having to modify the codebase.
>
What codebase changes concern you? If you do ResourceBundles correctly,
there really aren't any code changes. You simply throw ResourceBundles
for the appropriate languages into the jar and you should be good to go,
right?
> Anyway, we're British, the client's programmers are American (well,
> they're in America, and are either American or Indian), the
> contractors we had involved a while ago were Indian (a mix of hindi,
> telugu and malayalam speakers), and the client's HQ, including their
> infrastructure guys and the virtual machines where we all work, is in
> Denmark. We all work in english. I think the JVM default locale is
> en_US throughout.
>
> So, a daily feature of our project is an Indian programmer in an
> office in the US using a machine in Denmark to look at content in
> german which will be shown to customers in the Czech Republic.
>
> I have no idea if any of this answers your question.
>
I'm not sure either ;-) But it is interesting!
Do your classes have constructors (or getInstance() methods that
establish a Locale? Do you have setLocale() methods in your classes? If
you don't use either approach, how do you set the Locale and how do you
change it if it needs to be changed?
>> Also, is there much need for systems in which the user can switch
>> languages on the fly? In other words, let's say I'm working in a
>> system that uses French language ResourceBundles but am finding that
>> the French is not to my liking - maybe it's Quebecois instead of
>> Parisian - and I realize that I will understand better in my second
>> language, English, which I learned by watching MTV. Would a system
>> typically have the capability of letting the user invoke a switch to
>> another language via setLocale()? Or would I install an
>> English-language JVM and run my system on that?
>
> I wouldn't expect to have to install a second JVM. I also wouldn't
> expect to be able to change locale on the fly - i might try it, but i
> wouldn't be surprised if it didn't work. I would expect that i'd be
> able to get what i wanted by killing the system and restarting with
> the following parameters added to the java command line (assuming a
> Sun java):
>
> -Duser.language=en -Duser.country=GB
>
Yeah, that's a more convenient approach. I'd forgotten about setting the
locale from the command line.
>> Hold on, that doesn't quite make sense. I don't recall any language
>> selection option any time I've installed Java. The language of the
>> JVM comes from a system property which I can presumably change. Hmm,
>> I wonder if I should take a minute and switch my language to see what
>> kind of output I get from core Java classes. Will the message that
>> comes with my Exception be in the newly-chosen language?.... I should
>> answer this question for myself with a bit of experimentation....
>
> Experimentation is often a very good thing to do.
>
Now if only I had time to do everything I'd like to do .... ;-)
--
Rhino
Lew
Arne Vajhøj wrote:
>> That problem is not so important. You would not want to display
>> Java exception text to end-users anyway.
Rhino wrote:
> Really? I find that a surprising thing to say.
Exceptions are not for users, they're for code.
> Maybe we're not talking about the same thing.
You are.
> I'm thinking of a situation like completing a form in a GUI. The customer
> has to enter his date of birth. Let's say that I can't use a JSpinner for
> some reason; it can't do everything I need it to do. The customer is
> given a simple JTextField for entering a date. Clearly, the customer
> would have many opportunities to enter bad data. He could type in 1985-
> 15-31 when he meant to type 1985-05-01; the first value is obviously a
> bad date since there are only 12 months in the year, not 15. My practice
> is to write edits that check for that kind of mistake and generate an
> exception, typically IllegalArgumentException, with a clear error message
> that reminds the user that there is no such month as '15'. Naturally, the
> customer might not be an English speaker so I put all such messages in
> ResourceBundles so that other bundles can easily be added for any
> languages that I support.
You generate an error message for the customer, but it's not in the exception,
it's in what *handles* the exception.
In fact, with input validation, you wouldn't want to create, much less throw
an exception at all. Bad data is not part of the exceptional flow, it's part
of the normal flow and should be handled with conditionals.
Furthermore, runtime exceptions like IllegalArgumentException are for
programmer errors, not situational problems like failure to locate a file
(FileNotFoundException) or socket woes (SocketException), which are covered by
checked exceptions. You certainly don't want to talk to the user about
programmer errors.
> How would you handle such a situation?
Not use exceptions at all.
--
Lew
Rhino
> Rhino wrote:
>> Let's say that I want to make a static factory class locale-sensitive
>> but I don't want to force the user to choose an explicit locale every
>> time they try to use the class. That suggests to me that I go one of
>> two ways:
>>
>> 1. Provide two private constructors - one that takes a specified
>> locale and one that uses the default locale - and two corresponding
>> public getInstance() methods, one of which takes a specified locale
>> and one that uses the default locale. Then, if the user is
>> comfortable with the default locale, they use the constructor that
>> doesn't have a locale parameter, otherwise, they use the constructor
>> that has a locale parameter and specify the locale of their choice.
>
> Why do you want to provide factory classes at all?
>
(I saw your amendment saying you meant factory METHODS in that sentence.)
Actually, you and/or Eric (and maybe some others) persuaded me to use
factories for my utility methods several weeks back when I was asking
about the best way to set up my StringUtils class. You're not changing
your mind and advising me against that now are you?
Agreed. That's exactly what I meant; I just phrased it crudely in an
attempt to be brief. Clearly, the user is going to choose a different
language/locale from a GUI or something like that and is certainly not
going to type "new Locale("XX", "yy")" somewhere.
> You
> could just as easily instantiate a new object with a different locale
> in response to a user action as mutate an existing object.
>
which is why I'm struggling with this. When there are several ways to do
something, I'm not always clear on how to choose between them....
> In your particular case, I'd lay dollars to doughnuts that an
> immutable Locale attribute is the better solution.
>
Would it be helpful here to post one of my utility classes? One of them,
LocalizationUtils, is very short. Right now, it has two private
constructors, one that takes a Locale and one that doesn't, two
corresponding getInstance() methods, a getLocale() and a setLocale(),
plus three other short methods. I'm sure some of that is redundant; I'm
just trying to figure out which constructors and methods to eliminate to
make the final version of the class.
--
Rhino
Rhino
> On 21-05-2010 16:12, Rhino wrote:
>> In the course of developing test cases for some of my classes,
>> particularly the classes that are static factories, I've developed
>> some confusion about localization. Basically, I'm trying to figure
>> out when I want to have separate constructor and getInstance()
>> methods
>>
>> First, I hope we can all agree that, in an ideal world, every class
>> which can produce text output - even if no text is produced per se,
>> most classed would be capable of producing error messages for
>> Exceptions - should be written so that it can produce that output in
>> the languages of the users of those classes. So, if your utility
>> classes are used in French-speaking countries, text output and/or
>> error messages will be in French and so forth for other languages.
>> Now, I know that many developers will not worry about that - after
>> all, the whole IT field seems to be fairly English-centric - but I
>> aspire to make all of _my_ classes locale- sensitive.
>
> I think you are too ambitious.
>
Probably :-)
> Not everything need to be internationalized.
>
> Some forms of output are not even possible to internationalize
> (especially languages outside of the western countries can
> be difficult).
>
> You should focus on the output that is rich (looks good, has
> advanced capabilities).
>
> GUI's (both fat client and web) plus print intended for
> advanced printers (not line printers).
>
> Drop it for console IO, log files, print for line printers etc..
Some guidelines on when internationalization is appropriate are just what
I need. I appreciate your advice.
Sorry? I'm not clear on the distinction you're making in your note.
Are you envisioning that the invoking class do:
LocalizationUtils localizationUtils = LocalizationUtils.getInstance(new
Locale("FR", "fr));
Map<String, Locale> myLocales = localizationUtils.getLocales();
-OR-
LocalizationUtils localizationUtils = LocalizationUtils.getInstance();
localizationUtils.setLocale(new Locale("FR", "fr");
Map<String, Locale> myLocales = localizationUtils.getLocales();
Or did you mean something else altogether?
--
Rhino
Rhino
Agreed. I only mentioned text specifically but I have written code that
uses List, Text and Message bundles. I know how to use them all. I'm
still struggling a bit with the "big picture" stuff though so that's what
I'm asking about here.
--
Rhino
Rhino
I can imagine! I have a probably oversimplistic view that virtually all of
the developers out there have at least a working knowledge of English and
frequently much much better command of the language but that may be a
little overoptimistic :-) I can easily imagine a developer that has only a
fairly weak grasp of English and no knowledge whatever of French or German
- maybe an Asian for example - struggling to uncover the meaning of a
message that is probably cryptic even to a native English speaker! I know
I've seen a number of messages over the years that were (apparently)
written by native English speakers that were almost incomprehensible. I can
only imagine how hard these were for people whose English is less fluent
than mine.....
--
Rhino
Patricia Shanahan
> which is why I'm struggling with this. When there are several ways to do
> something, I'm not always clear on how to choose between them....
Have you done much background reading or studying on software
engineering ideas such as separation of concerns and design patterns?
For research type projects, where the requirements can change very
frequently, I tend towards an approach of initially implementing things
as simply as possible for the current requirements, but being very
willing to refactor.
Patricia
Eric Sosman
> Lew<no...@lewscanon.com> wrote in news:ht766u$dd3$1...@news.albasani.net:
>> Why do you want to provide factory classes at all?
>>
> (I saw your amendment saying you meant factory METHODS in that sentence.)
>
> Actually, you and/or Eric (and maybe some others) persuaded me to use
> factories for my utility methods several weeks back when I was asking
> about the best way to set up my StringUtils class. You're not changing
> your mind and advising me against that now are you?
He probably isn't. Factory methods are quite common; factory
*classes* are relatively rare. (You'll learn more about what's
what in a few years, when you've saved enough for "Effective Java,"
but until then you'll just have to take it on faith.)
> Agreed. That's exactly what I meant; I just phrased it crudely in an
> attempt to be brief.
Brevity is the soul of wit. Crudity is the soul of halfwit.
(And crudit�s are the life of the party, but I digest. Er, digress.)
--
Eric Sosman
eso...@ieee-dot-org.invalid
Lew
>>>> It has ever amazed me how well the Brits speak English. Awesome!
Mike Schilling wrote:
>>> Some of them even write it well, though rarely as well as the Irish.
Tom Anderson wrote:
>> And of course, it's the Scandinavians who are the real masters of it.
Mike Schilling wrote:
> I was thinking of Shaw, Wilde, Joyce, Synge, and Yeats.
Samuel Beckett, Jonathan Swift.
--
Lew
Lew
>>> Why do you want to provide factory classes at all?
Rhino wrote:
>> (I saw your amendment saying you meant factory METHODS in that sentence.)
>>
>> Actually, you and/or Eric (and maybe some others) persuaded me to use
>> factories for my utility methods several weeks back when I was asking
>> about the best way to set up my StringUtils class. You're not changing
>> your mind and advising me against that now are you?
Eric Sosman wrote:
> He probably isn't. Factory methods are quite common; factory
He saw my amendment that I meant factory methods, not classes.
> *classes* are relatively rare. (You'll learn more about what's
> what in a few years, when you've saved enough for "Effective Java,"
> but until then you'll just have to take it on faith.)
I did not "change my mind", nor do I recommend the use of factory methds
willy-nilly.
But I did not make a recommendation in my question, I asked a question. Why
are you providing factory methods at all?
There are reasons to provide a factory method. They do not always apply.
What are your reasons? Just answer the question.
--
Lew
Tom Anderson
> Tom Anderson <tw...@urchin.earth.li> wrote in
> news:alpine.DEB.1.10.1...@urchin.earth.li:
>
>> For instance, i'm currently on a project which will roll out to 23
>> countries in the first wave. They're all European and North Amererican,
>> and in a slightly weird twist, to begin with we're only supporting
>> english, french, and german as languages. So, if you're a native of the
>> UK, the US, Canada, France, Switzerland, Luxembourg or a few other
>> places, you have your own language, but if you live in Hungary or the
>> Netherlands, you'll have to be able to read english, or in some cases
>> in eastern Europe, german.
>
> Sorry for the off-topic digression but I just can't help but admit to
> some surprise that some eastern Europeans still know German.
Hey, don't look at me. I got the list of locales handed to me from someone
else, and he got it from someone else, and i assume that someone who knew
what they were doing drew it up. Or at least, i hope so; all i can assume
is that someone who had the authority to do it did it.
>> In the second wave, Korea will be added, and for that, there will be
>> korean. I assume that in later waves, there will be proper localisation
>> into national languages, but i haven't heard about that. By that point,
>> such localisation would not require programmer input (or at least only
>> a tiny bit) - the client's content management team will be able to add
>> new locales and their corresponding translations to the system
>> themselves. We're keeping translations in a database rather than
>> resource bundle files, so they can do this to a running system without
>> having to modify the codebase.
>
> What codebase changes concern you? If you do ResourceBundles correctly,
> there really aren't any code changes. You simply throw ResourceBundles
> for the appropriate languages into the jar and you should be good to go,
> right?
And then deploy the JAR and reboot. Not so hot if you're hoping to run a
global ecommerce site.
> Do your classes have constructors (or getInstance() methods that
> establish a Locale? Do you have setLocale() methods in your classes? If
> you don't use either approach, how do you set the Locale and how do you
> change it if it needs to be changed?
The system is a web application. We attach a locale to each user session.
We have a component near the top of the servlet container's request
processing chain that looks at the incoming request, and the existing user
object if there is one, and sets the locale accordingly. When a class
needs to know the current locale, it gets hold of the user object for the
current request (via some sort of thread-local variable or some such) and
asks it. So, no class inside the system has any concept of its own locale
- they always use the 'current locale', where that's something that can be
different in different threads that are running at the same time.
tom
--
build the roof with holes in
Arne Vajhøj
English is a mix of the languages of the invaders from
Germany, Scandinavia and France.
Arne
Arne Vajhøj
Do you just want to support western languages?
Or do you also want to solve the difficult problems?
>> That problem is not so important. You would not want to display
>> Java exception text to end-users anyway.
>>
> Really? I find that a surprising thing to say. Maybe we're not talking
> about the same thing.
>
> I'm thinking of a situation like completing a form in a GUI. The customer
> has to enter his date of birth. Let's say that I can't use a JSpinner for
> some reason; it can't do everything I need it to do. The customer is
> given a simple JTextField for entering a date. Clearly, the customer
> would have many opportunities to enter bad data. He could type in 1985-
> 15-31 when he meant to type 1985-05-01; the first value is obviously a
> bad date since there are only 12 months in the year, not 15. My practice
> is to write edits that check for that kind of mistake and generate an
> exception, typically IllegalArgumentException, with a clear error message
> that reminds the user that there is no such month as '15'. Naturally, the
> customer might not be an English speaker so I put all such messages in
> ResourceBundles so that other bundles can easily be added for any
> languages that I support.
>
> How would you handle such a situation?
Catch the exception but display something else that the exception text.
Exceptions texts are for log files to be handed over to developers.
For user input I don't even think that you should throw an
exception. Maybe just test and tell the user to correct.
Bad user input is not really exceptional enough to justify an
exception.
Arne
Arne Vajhøj
> Sorry for the off-topic digression but I just can't help but admit to
> some surprise that some eastern Europeans still know German. Stalin and
> his eastern European brothers were pretty ruthless about exiling or
> killing their German residents in the immediate aftermath of WW II. I had
> thought the German language was pretty much non-existent in the former
> Warsaw Pact area by this point.... Based on what you're saying, it
> appears that I was premature in assuming an absence of German in those
> countries.
There may be few ethnic Germans left in those countries.
But there are a lot of people that wants to do business
with German companies.
Arne
Arne Vajhøj
> For instance, i'm currently on a project which will roll out to 23
> countries in the first wave. They're all European and North Amererican,
> and in a slightly weird twist, to begin with we're only supporting
> english, french, and german as languages. So, if you're a native of the
> UK, the US, Canada, France, Switzerland, Luxembourg or a few other
> places, you have your own language, but if you live in Hungary or the
> Netherlands, you'll have to be able to read english, or in some cases in
> eastern Europe, german. In the second wave, Korea will be added, and for
> that, there will be korean. I assume that in later waves, there will be
> proper localisation into national languages, but i haven't heard about
> that. By that point, such localisation would not require programmer
> input (or at least only a tiny bit) - the client's content management
> team will be able to add new locales and their corresponding
> translations to the system themselves. We're keeping translations in a
> database rather than resource bundle files, so they can do this to a
> running system without having to modify the codebase.
There are increasing levels of difficulties of internationalization:
1) different language
2) different alphabet
3) different writing directions
If #3 does not require code changes, then somebody will have had
to planned very well.
Arne
Arne Vajhøj
True.
But the problem I describe is not that problem.
I am describing the problem of:
- developers being good at English
- operators being good at English
- for political reasons the GUI's are not in English but the
local language
- something is not working and the developers get some screen
shots and they can only say WTF
Arne
Arne Vajhøj
Something else.
LocalizationFactory lf = new LocalizationFactory();
lf.setLocale(new Locale("FR", "fr"));
X x = lf.getX();
Y y = lf.getY();
Z z = lf.getZ();
Arne
Lew
> English is a mix of the languages of the invaders from
> Germany, Scandinavia and France.
Of course, borrowing from any other language is far from taboo. It's enough
to drive you meshugge. Maybe some sleazy gigolo tycoon will fund an opera
about a funky zombie vampire who lives in an igloo, wearing a parka and
smoking cigars, then runs amok because people won't kowtow to him.
"English doesn't borrow from other languages. English follows other languages
down dark alleys, knocks them over, and goes through their pockets for loose
grammar."
- Paraphrased from James D. Nicoll
--
Lew
Tom Anderson
True. Everyone involved would, i think, be prepared to accept a redeploy
when we add RTL languages, or even ideographics. We'll also need to push
new versions whenever we roll out to countries which require more
significant structural changes - adding new country-specific behaviour to
the checkout flow for example (eg ISTR that in some middle eastern
countries the law requires that customers must give their national ID
number when buying anything online).
But it's nice to be able to push out new locales to existing countries (eg
adding danish to Denmark, which currently only has english) without a
redeploy, and it's absolutely essential to be able to push changed content
to an existing locale without taking down the system.
tom
--
One horse laugh is worth a thousand syllogisms. -- H. L. Mencken
Tom Anderson
I disagree. We've had arguments about the proper use of exceptions on this
newsgroup before, so i recognise that this is a matter where opinions
vary, but exceptions seem like a perfectly acceptable option for dealing
with bad user input to me. They might not be the right solution in every
situation, but they are an option that can be considered.
Of course, i wouldn't show the exception's error message to the user. An
approach i've seen is to do something like:
public class ValidationException extends Exception {
private final String validationKey;
private final Object[] parameters;
public ValidationException(String validationKey, Object.. parameters) {
super(format(validationKey, Locale.getDefault()));
this.validationKey = validationKey;
this.parameters = parameters;
}
public String format(Locale locale) {
return format(validationKey, locale);
}
private static String format(String validationKey, Locale locale) {
ResourceBundle bundle = ResourceBundle.getBundle("ValidationMessages", locale);
String pattern = bundle.getString(validationKey);
MessageFormat fmt = new MessageFormat(pattern, locale);
return fmt.format(parameters);
}
}
ValidationExceptions have a message in the language of the default locale
(or you could hardcode this to english if you wanted), which can be used
in logging and so on, but can also supply their message in other
languages, as needed.
If you put on a getter for the fields, then code that handles them can
also act on the key and parameters in other ways, as appropriate, if
simply printing the messasge is not adequate. Although in this case, you
should probably be using subclasses rather than switching on the contents
of the key. If you do subclass, you can refine the above approach by
pushing the parameters down into subclasses, accessed via an abstract
getParameters method in the base class. That lets you construct the array
on the fly from meaningful fields:
public class AgeTooYoungException extends ValidationException {
private final int actualAge;
private final int requiredAge;
// constructor
protected Object[] getParameters() {
return new Object[] {actualAge, requiredAge};
}
// getters
}
Code which catches this and is interested in the ages can then discover
them via proper getter calls, rather than having to scrub about in an
untyped parameter array.
Another refinement is to add a field which somehow indicates which bit of
user input was wrong - a simple string key might be enough. The UI code
can then attach the error message to the right bit of the UI simply by
matching that up.
Arne Vajhøj
> Code which catches this and is interested in the ages can then discover
> them via proper getter calls, rather than having to scrub about in an
> untyped parameter array.
>
> Another refinement is to add a field which somehow indicates which bit
> of user input was wrong - a simple string key might be enough. The UI
> code can then attach the error message to the right bit of the UI simply
> by matching that up.
The advantage of an exception over returning not valid is if there
is a deep call stack to skip.
The trend today seems to put validation out in the presentation/control
layer and then the need for exception does not really seems to be
there.
Arne
Lew
>> Bad user input is not really exceptional enough to justify an exception.
Tom Anderson wrote:
> I disagree. We've had arguments about the proper use of exceptions on
> this newsgroup before, so i [sic] recognise that this is a matter where
> opinions vary, but exceptions seem like a perfectly acceptable option
> for dealing with bad user input to me. They might not be the right
> solution in every situation, but they are an option that can be considered.
And usually rejected.
Read /Effective Java/ (2nd ed.), "Item 57: Use exceptions only for exceptional
conditions", and the rest of section 9.
Part of the problem with exceptions is that they are expensive relative to
conditionals.
The other part in this case is that you expect bad inputs - they aren't
exceptional conditions at all.
Your style is your style, tom, and you are absolutely correct to suggest that
one should consider all options. But the design purpose of exceptions is to
deal with out-of-line conditions, and input validation is squarely in line.
--
Lew
Rhino
news:8MOdnVeFX8O7qmXW...@earthlink.com:
> Rhino wrote:
>
>> which is why I'm struggling with this. When there are several ways to
>> do something, I'm not always clear on how to choose between them....
>
> Have you done much background reading or studying on software
> engineering ideas such as separation of concerns and design patterns?
>
Not enough, I'm afraid. I have spent a few hours a couple of times looking
at a few of the standard 21 (?) design patterns and have a link (or
several) to such discussions. But I don't THINK in patterns yet.
> For research type projects, where the requirements can change very
> frequently, I tend towards an approach of initially implementing
> things as simply as possible for the current requirements, but being
> very willing to refactor.
>
Absolutely! I think we should be very willing to be flexible, at least in
the early days of building a system when big changes in requirements (or
our understanding of them) come along regularly.
--
Rhino
Rhino
Sorry, I heard you the wrong way. I thought you were - in effect - saying
I was foolish to use them and should be doing something else. That was a
little disorienting since I think you were part of the discussion that
persuaded me to use static factory methods in the first place....
Well, on to your question as you intended it....
I have several utility classes, including StringUtils, DateTimeUtils, and
LocalizationUtils, that provide methods (frequently convenience methods)
to do such things as search a string for the number of occurrences of a
specific character, or determine the current day name, or to grab a
ResourceBundle. At a certain point, I was confused about whether these
methods should be static or not and I was persuaded that a static factory
method was the best way to go. Each user would do a getInstance() on the
class, then use whichever methods they wanted. That's what I've done.
If you are asking me to remember why this is a better way to go than the
alternatives, I'm embarassed to admit that I don't recall. Sometimes,
when I get persuaded to do something, I just do it and resolve to keep
doing it (and even retrofit existing code to use the technique) but I
don't necessarily remember why it is the best way. Maybe I should but I
don't....
--
Rhino
Rhino
That seems pretty much the same as Approach 2 to me, except that the
class is called LocalizationFactory instead of LocalizationUtils. Am I
missing something?
Is it considered a best practice to put Factory in the name of a utility
class that uses static getInstance() methods and private constructors? If
so, I have no problem doing that.
--
Rhino
Rhino
I see what you meant now. Yeah, that could be tricky! Then again, if the
GUI is identical except for the labels on the fields or buttons, then all
you really need to do is look at the English version of the GUI and
translate from there. So, if the leftmost menu item on the menu says
"Shizglop", just look at the leftmost menu item on the English version of
the GUI and it should be clear that "Shizglop" means "File".
Foreign language error messages are going to be a lot harder though. It's
not going to be apparent that "Floomba patixet snarblot" means "Please
enter password" ;-) Unless every error message contains a visible message
number like "XYZ123 Floomba patixet snarblot"; then you just look up
XYZ123 (assuming that's a unique message number) and then find that same
message in your English ResourceBundle.
A little tedious for sure but workable in a pinch. Or, you can spend time
and money finding someone who knows English and the local language. Mind
you, I would like to think that at least some of the better educated
people in the local office speak both the local language and English
moderately well, possibly well enough to get the essence of the problem
fairly directly....
--
Rhino
Rhino
I didn't realize you needed to reboot to get the new Jar to take effect.
That's lousy. Isn't it possible to simply refresh the new Jar in place
without rebooting? I'm pretty sure Tomcat lets you redeploy a Jar without
stopping Tomcat first but my Tomcat skills are rusty so I may be
wrong....
>> Do your classes have constructors (or getInstance() methods that
>> establish a Locale? Do you have setLocale() methods in your classes?
>> If you don't use either approach, how do you set the Locale and how
>> do you change it if it needs to be changed?
>
> The system is a web application. We attach a locale to each user
> session. We have a component near the top of the servlet container's
> request processing chain that looks at the incoming request, and the
> existing user object if there is one, and sets the locale accordingly.
> When a class needs to know the current locale, it gets hold of the
> user object for the current request (via some sort of thread-local
> variable or some such) and asks it. So, no class inside the system has
> any concept of its own locale - they always use the 'current locale',
> where that's something that can be different in different threads that
> are running at the same time.
>
I see. That sounds like a pretty reasonable design for your needs.
--
Rhino
Rhino
Oh! So applications are being deployed in German because the locals will be
communicating with head office in German, not because the locals are German
speakers! I hadn't considered that possibility. It makes sense though; some
of the Slavic countries still educate some of their people in the German
language despite their very bad memories of Hitler and WWII. I took a short
Russian course once and the teacher, a native Russian, had also studied
German quite extensively.
Also, I seem to remember a Pole telling me that Russian, which used to be
mandatory in Polish schools during the Cold War, has now been made optional
and many students are choosing to study German and other languages instead.
I suppose the eastern Europeans will take advantage of those students to
work with your system in German while they await eventual translation to
Hungarian, Polish or whatever....
--
Rhino
Martin Gregorie
>
> Foreign language error messages are going to be a lot harder though.
> It's not going to be apparent that "Floomba patixet snarblot" means
> "Please enter password" ;-) Unless every error message contains a
> visible message number like "XYZ123 Floomba patixet snarblot"; then you
> just look up XYZ123 (assuming that's a unique message number) and then
> find that same message in your English ResourceBundle.
>
> A little tedious for sure but workable in a pinch. Or, you can spend
> time and money finding someone who knows English and the local language.
> Mind you, I would like to think that at least some of the better
> educated people in the local office speak both the local language and
> English moderately well, possibly well enough to get the essence of the
> problem fairly directly....
>
I think you'll find that this is precisely the reason why DEC (while they
existed) and IBM tend to put such ugly prefixes on all their error
messages.
Its also easy to go further: given such tags its easy to support centre
software to take a trace etc. from a site anywhere in the world and and
make it understandable to the support guy no matter what language he
speaks. If you're supporting a multi-language application then IMO such a
translation package should automatically be a part of the project.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
RedGrittyBrick
> Arne Vajhøj<ar...@vajhoej.dk> wrote in
>>
>> I am describing the problem of:
>> - developers being good at English
>> - operators being good at English
>> - for political reasons the GUI's are not in English but the
>> local language
>> - something is not working and the developers get some screen
>> shots and they can only say WTF
>>
> I see what you meant now. Yeah, that could be tricky! Then again, if the
> GUI is identical except for the labels on the fields or buttons, then all
> you really need to do is look at the English version of the GUI and
> translate from there. So, if the leftmost menu item on the menu says
> "Shizglop", just look at the leftmost menu item on the English version of
> the GUI and it should be clear that "Shizglop" means "File".
Can you be sure that what is leftmost in a left-to-right script is also
leftmost in a right-to-left script?
> Foreign language error messages are going to be a lot harder though. It's
> not going to be apparent that "Floomba patixet snarblot" means "Please
> enter password" ;-) Unless every error message contains a visible message
> number like "XYZ123 Floomba patixet snarblot"; then you just look up
> XYZ123 (assuming that's a unique message number) and then find that same
> message in your English ResourceBundle.
That's a very venerable tradition. Clearly it is very useful when the
user and support staff don't speak each other's languages well enough to
accurately translate arcane technical jargon to each other.
I can't see it working for anything other than error messages though.
You wouldn't have an identifying number on every button, label and other
widget.
> A little tedious for sure but workable in a pinch. Or, you can spend time
> and money finding someone who knows English and the local language. Mind
> you, I would like to think that at least some of the better educated
> people in the local office speak both the local language and English
> moderately well, possibly well enough to get the essence of the problem
> fairly directly....
Have you ever provided telephone support to people with the *same*
mother-tongue as yourself? Even when there shouldn't a language barrier,
there often is. Even with people who are otherwise intelligent and
articulate. It must surely be usually much worse when one of you is
speaking a second or third language.
I'm not sure what my point is, maybe that not every problem has a
technological solution :-)
--
RGB
Arne Vajhøj
Under good circumstances it is not that hard.
But over the phone in the middle of night ...
Arne
Arne Vajhøj
> Arne Vajh�j<ar...@vajhoej.dk> wrote in
> news:4bf86b7c$0$281$1472...@news.sunsite.dk:
>
>> On 22-05-2010 15:17, Rhino wrote:
>>> Sorry for the off-topic digression but I just can't help but admit to
>>> some surprise that some eastern Europeans still know German. Stalin
>>> and his eastern European brothers were pretty ruthless about exiling
>>> or killing their German residents in the immediate aftermath of WW
>>> II. I had thought the German language was pretty much non-existent in
>>> the former Warsaw Pact area by this point.... Based on what you're
>>> saying, it appears that I was premature in assuming an absence of
>>> German in those countries.
>>
>> There may be few ethnic Germans left in those countries.
>>
>> But there are a lot of people that wants to do business
>> with German companies.
>>
> Oh! So applications are being deployed in German because the locals will be
> communicating with head office in German, not because the locals are German
> speakers! I hadn't considered that possibility.
It is more like:
- people learn German for commercial reasons
- the software offers a few languages but not the native language
- they pick German because the prefer that over the other alternatives
Very few apps support all European languages. It is rather common to
support English, Spanish, French and German. And let the users pick the
one they understand best.
Arne
Arne Vajhøj
Maybe not.
I just wanted to make sure that the Local could be set once (either
constructor or setter) instead of multiple times in the get instance
methods or set methods on the individual objects.
> Is it considered a best practice to put Factory in the name of a utility
> class that uses static getInstance() methods and private constructors? If
> so, I have no problem doing that.
I would tend to put factory in the name of a factory class. It
describes what it does.
Util more indicates a utility method = a method that does
something that the calling code could do in multiple lines,
but has been centralized in a method.
Arne
Arne Vajhøj
And X, Y and Z obviously does not have private constructors,
because then LocalizationFactory could not instantiate them.
Arne
Arne Vajhøj
>> a global ecommerce site.
>>
> I didn't realize you needed to reboot to get the new Jar to take effect.
> That's lousy. Isn't it possible to simply refresh the new Jar in place
> without rebooting? I'm pretty sure Tomcat lets you redeploy a Jar without
> stopping Tomcat first but my Tomcat skills are rusty so I may be
> wrong....
If you can discard the classloader, then you can do that instead
of restarting the JVM.
But it is still an interruption of production.
In tomcat that is what happens when you restart just the app
and not the entire server.
Arne
Lew
>> "Floomba patixet snarblot"
Klaatu barada nikto!
--
Lew
Rhino
The Day the Earth Stood Still.... :-)
Rhino
Whatever happened to the time-honoured tradition of maintenance
windows? I don't think I've ever heard of a system that was truly 24 x
7. All of them used to have scheduled downtimes (or at least the
option of having downtimes as needed) for things like taking backups
and so forth. Do real-life Internet online systems _really_ promise 24
x 7? Don't the executives and/or lawyers build in at least some
provisions for downtime into their contracts?
I'm sure that people buying systems push for those downtimes to be as
brief and infrequent as possible but surely their must be _some_
provision for it in web-based systems? Or am I behind the times?
--
Rhino
Rhino
> >> I think it depends a lot of the context you develop software in.
>
> >> Global or local development?
>
> >> global => do development in English
> >> local => pick English or local language as you prefer
>
> >> Are you developing single-customer project-style software or
> >> multi-customer product-style software?
>
> >> product => internationalize, have English and then add to
> >> supported languages as customers require them (note that
> >> customers can want 3 things A) English version, B) local
> >> version C) Choice of English for local for end users
>
> >> project => whatever the customer wants
>
> >> And then we have not even talked about interesting countries
> >> like Belgium and Switzerland with multiple official languages
> >> (Canada is easier because one of the languages is English).
>
> >> That is not a clear answer, but it is a complex question!
>
> > It certainly is. I'm trying to write code that will be easily usable by
> > non-English speakers. But my code isn't actually being written for a
> > specific customer at this time, other than me. At the moment, I'm trying
> > to put together a sort of code portfolio. I'm hoping it will show
> > prospective employers or clients that I am culturally sensitive enough to
> > write code that will work in multiple languages and knowledgeable on how
> > to do it. In other words, I don't just want to claim that I am culturally
> > sensitive but then have no code to back that up. When they challenge me
> > to prove that I can write code that works for customers in various
> > locales, I want to be able to point them to some decent examples where I
> > have done that. I'm just trying to figure out the best way to do that
> > right now.....
>
> Do you just want to support western languages?
>
> Or do you also want to solve the difficult problems?
>
>
>
> >> That problem is not so important. You would not want to display
> >> Java exception text to end-users anyway.
>
> > Really? I find that a surprising thing to say. Maybe we're not talking
> > about the same thing.
>
> > I'm thinking of a situation like completing a form in a GUI. The customer
> > has to enter his date of birth. Let's say that I can't use a JSpinner for
> > some reason; it can't do everything I need it to do. The customer is
> > given a simple JTextField for entering a date. Clearly, the customer
> > would have many opportunities to enter bad data. He could type in 1985-
> > 15-31 when he meant to type 1985-05-01; the first value is obviously a
> > bad date since there are only 12 months in the year, not 15. My practice
> > is to write edits that check for that kind of mistake and generate an
> > exception, typically IllegalArgumentException, with a clear error message
> > that reminds the user that there is no such month as '15'. Naturally, the
> > customer might not be an English speaker so I put all such messages in
> > ResourceBundles so that other bundles can easily be added for any
> > languages that I support.
>
> > How would you handle such a situation?
>
> Catch the exception but display something else that the exception text.
>
> Exceptions texts are for log files to be handed over to developers.
>
> For user input I don't even think that you should throw an
> exception. Maybe just test and tell the user to correct.
>
> exception.
>
I'm not disagreeing with you but isn't there some leverage to be
obtained from using the same message to do both: inform the user of a
problem and write it to the log if it is sufficiently severe?
I suppose you would argue that the two cases are mutually exclusive:
any situation serious enough to justify a log message would generate
its message in an entirely different way (from a different place) than
a "user error" message....
So, am I safe in assuming that serious developers are generating "user
messages", like bad input on a form, from ResourceBundles and
"serious" errors for logs and such things from some other source,
perhaps hard-coded within the class itself?
Rhino
opinions were united on the idea that exceptions had no place in
notifying users about "user errors" (as opposed to "system errrors").
That's a "good news, bad news" scenario as I see it: if everyone
agreed how to do it, it would be up to me to conform with the
concensus and I wouldn't have to think about what should be done very
much. But if there are different schools of thought on the issue, I
could show any reasonable approach in my "code portfolio" and still be
okay, although I might have to be able to defend whatever approach I
used against the other approaches.....
Arne Vajhøj
> On May 23, 6:35 pm, Arne Vajh�j<a...@vajhoej.dk> wrote:
>> On 23-05-2010 17:33, Rhino wrote:
>>
>>> Tom Anderson<t...@urchin.earth.li> wrote in
>>>> And then deploy the JAR and reboot. Not so hot if you're hoping to run
>>>> a global ecommerce site.
>>
>>> I didn't realize you needed to reboot to get the new Jar to take effect.
>>> That's lousy. Isn't it possible to simply refresh the new Jar in place
>>> without rebooting? I'm pretty sure Tomcat lets you redeploy a Jar without
>>> stopping Tomcat first but my Tomcat skills are rusty so I may be
>>> wrong....
>>
>> If you can discard the classloader, then you can do that instead
>> of restarting the JVM.
>>
>> But it is still an interruption of production.
>>
>> In tomcat that is what happens when you restart just the app
>> and not the entire server.
>
> windows? I don't think I've ever heard of a system that was truly 24 x
> 7. All of them used to have scheduled downtimes (or at least the
> option of having downtimes as needed) for things like taking backups
> and so forth. Do real-life Internet online systems _really_ promise 24
> x 7? Don't the executives and/or lawyers build in at least some
> provisions for downtime into their contracts?
>
> I'm sure that people buying systems push for those downtimes to be as
> brief and infrequent as possible but surely their must be _some_
> provision for it in web-based systems? Or am I behind the times?
It depends on the context.
For many internal systems then nightly downtime is still
acceptable.
But the world has become global. It is always work hours
somewhere on the planet.
Public internet systems like Google and FaceBook does
not close a couple of hours every day.
Huge multinational corporations with offices in almost
all timezones can not shutdown business critical system
a couple of hours every day.
Nightly downtime still exists but it is definitely
out of fashion today.
Many business system still have weekly/monthly
scheduled downtime though.
But Google/FaceBook types does not even have that.
Arne
Arne Vajhøj
In most cases I don't think the exception text would
tell the end user anything.
Let us say that you have developed an accounting program and
the code throws an exception telling that it could not
load the JDBC driver.
No point in telling an accountant that. He don't know what
JDBC is.
You tell the accountant that there were a configuration error
and that he should contact his IT department.
You write in the log file what the problem is and when IT
support look at the log file, then they know what the
problem is.
Of course there are cases where the message text from the
exception can be used in the end user error text. Just don't
display class names, stack traces etc..
Arne
Arne Vajhøj
> I'm glad you jumped in on this point, Tom. I thought for a second that
> opinions were united on the idea that exceptions had no place in
> notifying users about "user errors" (as opposed to "system errrors").
> That's a "good news, bad news" scenario as I see it: if everyone
> agreed how to do it, it would be up to me to conform with the
> concensus and I wouldn't have to think about what should be done very
> much. But if there are different schools of thought on the issue, I
> could show any reasonable approach in my "code portfolio" and still be
> okay, although I might have to be able to defend whatever approach I
> used against the other approaches.....
It will not get you thrown out the door. But if the call stack between
throw and catch is less than 2 levels, then I would consider it
bad style. Much better with something that test and return true
or false.
Arne
Patricia Shanahan
That tends to lead to very artificial handling of the result of the
input processing. To me, it makes a lot of sense to have a conversion
method that normally returns the converted value, and throws an
exception if it cannot do so because of an error in the data it is
converting.
Patricia
Arne Vajhøj
But when it is user input, then it is really not that exceptional
with format errors.
If it was reading a file that was generated by a system, then I
would consider a format error exceptional.
Even for unexceptional stuff an exception can be practical to
roll back the call stack, but if that is not the case either,
then I don't consider exception attractive.
A very good example is that .NET in 1.1->2.0 supplemented
the int.Parse method with a new int.TryParse method - today
the later is used in >90% of all cases.
Arne
Tom Anderson
> Arne Vajh?j wrote:
>>> Bad user input is not really exceptional enough to justify an exception.
>
> Tom Anderson wrote:
>> I disagree. We've had arguments about the proper use of exceptions on
>> this newsgroup before, so i [sic] recognise that this is a matter where
>> opinions vary, but exceptions seem like a perfectly acceptable option
>> for dealing with bad user input to me. They might not be the right
>> solution in every situation, but they are an option that can be considered.
>
> And usually rejected.
>
> Read /Effective Java/ (2nd ed.), "Item 57: Use exceptions only for
> exceptional conditions", and the rest of section 9.
No.
> Part of the problem with exceptions is that they are expensive relative
> to conditionals.
True. I wouldn't worry about that in input validation code of this kind
unless i had a profiler screaming at me that it was a problem.
Hmm. Do profilers track the amount of time the JVM spends handling
exceptions?
> The other part in this case is that you expect bad inputs - they aren't
> exceptional conditions at all.
>
> Your style is your style, tom, and you are absolutely correct to suggest that
> one should consider all options. But the design purpose of exceptions is to
> deal with out-of-line conditions, and input validation is squarely in line.
I don't agree that bad input is not an exceptional condition; i wonder if
you are confusing 'exceptional' and 'unlikely' or 'unexpected'. I agree
that validating input must be done inline, but not that dealing with
invalid input must be. I'd say exactly the opposite, in fact.
tom
--
The exact mechanics are unknown, but a recent sound file revealed the
process to go something like this: WONKA WONKA WONKA WONKA DEOO DEOO
DEOO DEOO WOWOWOWOWOWOWOWOWOWOWOW WONKA WONKA WONKA...
Tom Anderson
> On 23-05-2010 20:18, Rhino wrote:
We're no Google, and we will have downtime when we do need to update the
code. But pushing new content may well be happening on a daily basis, and
we don't want daily maintenance outages.
Mind you, if you have a cluster of app servers, you can update the code on
a machine-by-machine basis without ever taking the whole cluster down.
Provided you don't change the interface between machines, that is. I
anticipate that we'd be able to do this, althoug whether it'll be
considered worth setting up to avoid a few minutes of downtime, i don't
know.
Tom Anderson
> On 23-05-2010 23:33, Patricia Shanahan wrote:
>> Arne Vajh?j wrote:
>>> On 23-05-2010 20:32, Rhino wrote:
>>>> On May 23, 7:18 am, Tom Anderson<t...@urchin.earth.li> wrote:
>>>>
>>>>> I disagree. We've had arguments about the proper use of exceptions
>>>>> on this newsgroup before, so i recognise that this is a matter where
>>>>> opinions vary, but exceptions seem like a perfectly acceptable
>>>>> option for dealing with bad user input to me. They might not be the
>>>>> right solution in every situation, but they are an option that can
>>>>> be considered.
>>>>
Shocking.
Arne Vajhøj
> On Sun, 23 May 2010, Lew wrote:
>
>> Arne Vajh?j wrote:
>>>> Bad user input is not really exceptional enough to justify an
>>>> exception.
>>
>> Tom Anderson wrote:
>>> I disagree. We've had arguments about the proper use of exceptions on
>>> this newsgroup before, so i [sic] recognise that this is a matter where
>>> opinions vary, but exceptions seem like a perfectly acceptable option
>>> for dealing with bad user input to me. They might not be the right
>>> solution in every situation, but they are an option that can be
>>> considered.
>>
>> And usually rejected.
>>
>> Read /Effective Java/ (2nd ed.), "Item 57: Use exceptions only for
>> exceptional conditions", and the rest of section 9.
>
> No.
It is always good to read opinions from qualified people even
if you disagree with them.
>
>> Part of the problem with exceptions is that they are expensive
>> relative to conditionals.
>
> True. I wouldn't worry about that in input validation code of this kind
> unless i had a profiler screaming at me that it was a problem.
>
> Hmm. Do profilers track the amount of time the JVM spends handling
> exceptions?
If it is interactive user input then the overhead of exceptions
will be unmeasurable due the ratio between CPU speed and human
typing speed.
I don't think performance is the best argument against exceptions
for bad user input.
>> The other part in this case is that you expect bad inputs - they
>> aren't exceptional conditions at all.
>>
>> Your style is your style, tom, and you are absolutely correct to
>> suggest that one should consider all options. But the design purpose
>> of exceptions is to deal with out-of-line conditions, and input
>> validation is squarely in line.
>
> I don't agree that bad input is not an exceptional condition; i wonder
> if you are confusing 'exceptional' and 'unlikely' or 'unexpected'. I
> agree that validating input must be done inline, but not that dealing
> with invalid input must be. I'd say exactly the opposite, in fact.
You are free to have your opinion - just note that a lot
of people disagree today.
Arne
Patricia Shanahan
...
> But when it is user input, then it is really not that exceptional
> with format errors.
>
> If it was reading a file that was generated by a system, then I
> would consider a format error exceptional.
Reading these two paragraphs, I think the difference between us is the
viewpoint we use in evaluating "exceptional". You seem to be using a
whole program viewpoint. I look at it much more locally.
Typically, in my code, a String conversion method has no idea whether
the String it is converting came from a GUI TextField, an input file
edited by a user, or a file that was generated automatically. Its design
cannot and should not depend on whether an inability to do the
conversion is due to an error in a user input or in a system generated
input.
Instead, I look at the issue from the point of view of the method I'm
defining. What is the primary function of this method? If its primary
job is conversion of a String to some other type of value, and it cannot
do it because of incorrect content in the String, it throws an exception.
Of course, somewhere in the call stack there is a method that does know
where the unconvertible String came from. If the condition is not
exceptional from its point of view, it should catch the exception and
take appropriate action.
Patricia
Tom Anderson
> On 24-05-2010 08:12, Tom Anderson wrote:
>> On Sun, 23 May 2010, Lew wrote:
>>
>>> Arne Vajh?j wrote:
>>>>> Bad user input is not really exceptional enough to justify an
>>>>> exception.
>>>
>>> Tom Anderson wrote:
>>>> I disagree. We've had arguments about the proper use of exceptions on
>>>> this newsgroup before, so i [sic] recognise that this is a matter where
>>>> opinions vary, but exceptions seem like a perfectly acceptable option
>>>> for dealing with bad user input to me. They might not be the right
>>>> solution in every situation, but they are an option that can be
>>>> considered.
>>>
>>> And usually rejected.
>>>
>>> Read /Effective Java/ (2nd ed.), "Item 57: Use exceptions only for
>>> exceptional conditions", and the rest of section 9.
>>
>> No.
>
> It is always good to read opinions from qualified people even
> if you disagree with them.
True. But i don't have that book, and i'm not about to rush out and buy it
because it contains advice i disagree with! If i come across a copy of it
(i might be able to borrow one from the tribe upstairs at some point), i
will certainly read this.
>>> Part of the problem with exceptions is that they are expensive
>>> relative to conditionals.
>>
>> True. I wouldn't worry about that in input validation code of this kind
>> unless i had a profiler screaming at me that it was a problem.
>>
>> Hmm. Do profilers track the amount of time the JVM spends handling
>> exceptions?
>
> If it is interactive user input then the overhead of exceptions
> will be unmeasurable due the ratio between CPU speed and human
> typing speed.
>
> I don't think performance is the best argument against exceptions
> for bad user input.
Needless to say!
>>> The other part in this case is that you expect bad inputs - they
>>> aren't exceptional conditions at all.
>>>
>>> Your style is your style, tom, and you are absolutely correct to
>>> suggest that one should consider all options. But the design purpose
>>> of exceptions is to deal with out-of-line conditions, and input
>>> validation is squarely in line.
>>
>> I don't agree that bad input is not an exceptional condition; i wonder
>> if you are confusing 'exceptional' and 'unlikely' or 'unexpected'. I
>> agree that validating input must be done inline, but not that dealing
>> with invalid input must be. I'd say exactly the opposite, in fact.
>
> You are free to have your opinion - just note that a lot
> of people disagree today.
I certainly recognise that. And am used to it :).
tom
--
Vive la chimie, en particulier, et la connaissance en general. --
Herve This
Rhino
I completely agree with your argument in this scenario.
I was thinking more of cases where user input is faulty and could be
corrected by the user. For instance, I have a little GUI-based "color
converter" class: it has an input field where I type the hex
representation of a Color, e.g. FFCC00, and it gives me the RGB
representation, e.g. 25, 204, 0, in another field when I click on the
Convert button. Now, if the user mistypes the hex reprsentation of the
color, say FFCCZZ, the method that does the conversion detects that ZZ is
not a valid hex representation of the Blue component of a Color, throws
an IllegalArgumentExpection with text to that effect (the message is
retrieved from a ResourceBundle to allow for internationalization) and
then the try/catch block in the ColorConverter class displays that
message in a JOptionPane so that the user knows what to fix.
I don't log any of this and certainly don't show the user anything like a
stacktrace; just the message from the ResourceBundle.
That's a reasonable approach, isn't it?
--
Rhino
Rhino
wrote:
> In the course of developing test cases for some of my classes,
> particularly the classes that are static factories, I've developed some
> confusion about localization. Basically, I'm trying to figure out when I
> want to have separate constructor and getInstance() methods
>
> First, I hope we can all agree that, in an ideal world, every class which
> can produce text output - even if no text is produced per se, most
> classed would be capable of producing error messages for Exceptions -
> should be written so that it can produce that output in the languages of
> the users of those classes. So, if your utility classes are used in
> French-speaking countries, text output and/or error messages will be in
> French and so forth for other languages. Now, I know that many developers
> will not worry about that - after all, the whole IT field seems to be
> fairly English-centric - but I aspire to make all of _my_ classes locale-
> sensitive.
>
>
> Let's say that I want to make a static factory class locale-sensitive but
> I don't want to force the user to choose an explicit locale every time
> they try to use the class. That suggests to me that I go one of two ways:
>
> 1. Provide two private constructors - one that takes a specified locale
> and one that uses the default locale - and two corresponding public
> getInstance() methods, one of which takes a specified locale and one that
> uses the default locale. Then, if the user is comfortable with the
> default locale, they use the constructor that doesn't have a locale
> parameter, otherwise, they use the constructor that has a locale
> parameter and specify the locale of their choice.
>
> 2. Provide a single private constructor that has no locale parameter and
> a corresponding public getInstance() method. Also provide getLocale() and
> setLocale() methods so that a user can instantiate with the single
> getInstance() method and then use setLocale() to alter that locale if it
> is not to his liking.
>
> I thought I'd have a look at the Java API and see what happens there. I
> got something of a mixed bag. A handful of classes have getInstance()
> methods that take a Locale parameter, suggesting that they favour
> Approach 1. A handful of classes have setLocale() methods, suggesting
> that they favour Approach 2. However, the vast, vast majority of the
> classes have neither suggesting that they are NOT locale-sensitive and
> have no capability for changing the Locale at all.
>
> on which approach they'd take when building classes that are meant to be
> locale-sensitive. I'm sure there are variations on the two approaches
> I've enumerated so I'm open to "none of the above" answers :-)
>
> Personally, I'm leaning towards Approach 2. Approach 1 requires doubling
> up of constructors and getInstance() methods and makes you reinstantiate
> the class if you want to change Locales. Approach 2 avoids those extra
> constructors and getInstance() methods and lets you change Locale by
> simply doing setLocale(). There may be negative aspects to that which
> aren't occuring to me though so I hope you will point those out if you
> see them.
>
I've learned a lot in this thread about different aspects of i18n/l10n
(internationalization/localization) and I still expect to learn a bit
more as people respond to my scenario about my little Color Converter
program.... I thank you all for supplying considerations I hadn't
thought of in the design decisions that go with i18n/l10n.
But I'd like to try to sum up a bit now. The conversation has gotten
sufficiently fragmented that I'm not sure what we would all agree on
with regards to the situation I am trying to resolve.
In a nutshell, I have some utility-type classes and I am trying to
figure out how they should best handle matters of Locale.
Notice that I said "utility-TYPE classes". I initially described these
as static factory classes but I'm no longer sure that they should be.
Until a few months ago, all of the methods in these classes were
static and there was no constructor for the class. I had some concerns
and asked about them on a thread here. I don't recall how to give a
URL for a Google Groups discussion so I apologize for not being able
to give you one but it was a discussion that started March 15 2010 and
was entitled "Design Question". In a nutshell, because I had a Locale
variable in the class, this was seen as an element of 'state" for the
class and therefore I was advised to change the class so that it had a
private constructor and a public static getInstance() method. I did
that and, in fact, had two of each: a constructor that took no
parameters and one that took Locale as the parameter, and
corresponding getInstance() methods. I understand why the 'state'
necessitated this kind of change now that I've reread that thread.
However, I find myself seriously doubting that Locale SHOULD be a
class variable after all. And if my reasoning is sound, which I hope
you will tell me, I may be able to go back to having all the methods
be static.
As I look at the classes in the Java API, only a tiny handful of them
have constructors that take a Locale as an argument and only a tiny
handful have setLocale methods. Assuming that the Java API is
considered well-designed by the Java community - and I have to hope it
is :-) - that tells me that the remaining 99.9% of classes are
expecting to provide any locale-specific information in only ONE
Locale. Furthermore, no class invoking the API is typically going to
want to get the information in more than one language at a go.
Essentially, the classes operate on the basis of the Locale defined by
the user.country and user.language properties. Therefore, if my
properties are set to English and Canada, that is the locale that the
JVM is going to try to find - of course it will settle for other
flavours of English if there is no specific en_CA resource bundle -
and use for any other locale-specific text. (DateFormats,
NumberFormats, and their kin handle the localization needs of those
special kinds of data.)
Providing a way to set a specific Locale and even to change that
Locale on the fly so that classes could potentially invoke the class
repeatedly for different Locales is simply overbuilding and is almost
certainly not necessary at all! (I say 'almost' in deference to Lew's
observations about there being no hard and fast rules, which makes a
lot of sense to me.) So I think I can dispose of Locale in
constructors (and their associated getInstance() methods altogether.
Likewise, I can omit and setLocale() and/or getLocale() methods from
my utility classes too. Methods that seek to get ResourceBundles will
simply seek them for the default Locale, as determined via
Locale.getDefault().
Does this all make sense so far? I sure hope it does because I think
I've got myself convinced :-)
The classes will still be fully locale-sensitive; I've proven that by
simply changing user.language and user.country to other values and
information comes out in the desired language just fine. (My
writeLocales() methods writes the display names of the Locales in the
language of the default locale so if my default Locale is en_CA, I get
them in English but if it is de_DE, I them in German, etc.)
As someone interested in the issue of supporting different languages
in a syste, I did some dabbling with the i18n stuff shortly after it
came out. I wrote simple apps that would display a list of locales and
let the user choose their favourite, then go back to the menu and
change them on so that information would be redisplayed in the
replacement Locale. I got in the habit of putting that kind of code in
many of my classes on the theory that I was making them more flexible
but I had never really given a lot of thought to how realistic this
was or how it conformed with the far better designed Java API. Now I
see that it is just unneeded frippery. If a class's methods really do
need to be able to change Locales on the fly, I think I'll be able to
write the code to enable that. But those needs should be few and far
between. For now, I think I should abandon any efforts to have
"dynamic locale switching" (for want of a better term) in my classes.
Am I on the right track here? Or am I throwing out the baby with the
bathwater?
Once we are agreed on that, I would like to follow up with a few
specific detailed questions but I'd like to get the fundamental
principle resolved first.
--
Rhino
Lew
> I was thinking more of cases where user input is faulty and could be
> corrected by the user. For instance, I have a little GUI-based "color
> converter" class: it has an input field where I type the hex
> representation of a Color, e.g. FFCC00, and it gives me the RGB
> representation, e.g. 25, 204, 0, in another field when I click on the
> Convert button. Now, if the user mistypes the hex reprsentation of the
> color, say FFCCZZ, the method that does the conversion detects that ZZ is
> not a valid hex representation of the Blue component of a Color, throws
> an IllegalArgumentExpection with text to that effect (the message is
> retrieved from a ResourceBundle to allow for internationalization) and
> then the try/catch block in the ColorConverter class displays that
> message in a JOptionPane so that the user knows what to fix.
>
> I don't log any of this and certainly don't show the user anything like a
> stacktrace; just the message from the ResourceBundle.
I recommend against popping a dialog or other window in a try/catch block.
Try/catch is for getting out of a mess. If there's a lot of code in there,
you risk getting in another mess.
You also don't separate concerns enough, in this case the "happy-path" logic
from the error-message logic.
Plus, your validation is likely, or should be likely to be off the Event
Dispatch Thread (EDT), since validation isn't really a graphic action but a
logical one. That involves thread coordination from inside a try/catch, not
so good.
Let the catch block cause a return from the validator, and let the caller of
the validator decide where to go next.
--
Lew
Arne Vajhøj
> But I'd like to try to sum up a bit now. The conversation has gotten
> sufficiently fragmented that I'm not sure what we would all agree on
> with regards to the situation I am trying to resolve.
> However, I find myself seriously doubting that Locale SHOULD be a
> class variable after all. And if my reasoning is sound, which I hope
> you will tell me, I may be able to go back to having all the methods
> be static.
>
> As I look at the classes in the Java API, only a tiny handful of them
> have constructors that take a Locale as an argument and only a tiny
> handful have setLocale methods. Assuming that the Java API is
> considered well-designed by the Java community - and I have to hope it
> is :-) - that tells me that the remaining 99.9% of classes are
> expecting to provide any locale-specific information in only ONE
> Locale.
Note that the Java API is a low level API and localization is
most relevant for higher level business app code.
The huge majority of Java API classes does not have any
need for localization at all.
> Furthermore, no class invoking the API is typically going to
> want to get the information in more than one language at a go.
> Essentially, the classes operate on the basis of the Locale defined by
> the user.country and user.language properties. Therefore, if my
> properties are set to English and Canada, that is the locale that the
> JVM is going to try to find - of course it will settle for other
> flavours of English if there is no specific en_CA resource bundle -
> and use for any other locale-specific text. (DateFormats,
> NumberFormats, and their kin handle the localization needs of those
> special kinds of data.)
>
> Providing a way to set a specific Locale and even to change that
> Locale on the fly so that classes could potentially invoke the class
> repeatedly for different Locales is simply overbuilding and is almost
> certainly not necessary at all! (I say 'almost' in deference to Lew's
> observations about there being no hard and fast rules, which makes a
> lot of sense to me.) So I think I can dispose of Locale in
> constructors (and their associated getInstance() methods altogether.
> Likewise, I can omit and setLocale() and/or getLocale() methods from
> my utility classes too. Methods that seek to get ResourceBundles will
> simply seek them for the default Locale, as determined via
> Locale.getDefault().
That strategy may work OK for fat client apps. It will not work
well for the server side code in web apps.
Arne
Arne Vajhøj
> On Mon, 24 May 2010, Arne Vajh?j wrote:
>> On 24-05-2010 08:12, Tom Anderson wrote:
>>> On Sun, 23 May 2010, Lew wrote:
>>>> Read /Effective Java/ (2nd ed.), "Item 57: Use exceptions only for
>>>> exceptional conditions", and the rest of section 9.
>>>
>>> No.
>>
>> It is always good to read opinions from qualified people even
>> if you disagree with them.
>
> True. But i don't have that book, and i'm not about to rush out and buy
> it because it contains advice i disagree with! If i come across a copy
> of it (i might be able to borrow one from the tribe upstairs at some
> point), i will certainly read this.
There are other good sections in the book as well.
Put it on your Christmas gift wish list!
Arne
Arne Vajhøj
That is a core problem of the domain logic exceptional criteria. If we
are in the low level API, then we don't have a clue about what is
exceptional.
I would say that from a purity perspective "unknown" would favor
return value over exception, because I like the "convert return
value to an exception at a higher level" a lot more than
the "convert exception to return value at a higher level".
But the practical perspective this situation would favor
exception, because the call stack is often deep and the
exception is simply an easy way to get out to where
it is needed.
Well - I guess there is a reason that programmers will not
be replaced by AI programs soon.
:-)
Arne
Arne Vajhøj
> Arne Vajh�j<ar...@vajhoej.dk> wrote in
It is an OK approach.
A possible alternative could be to throw a custom exception
NotHexColorStringException and let the exception handling
code read the localized text.
Arne
Rhino
Can you point me to any examples that show input error handling done
right? I'm not following your proposal very clearly with just the English
description; I need to see some code.
Even though my code:
a) works
b) is very simple
it is apparently not what the doctor ordered and I need to rethink yet
another major aspect of my code....
--
Rhino
Rhino
Okay, I'll give that some thought.
But it sounds like you are saying that this is not the routine or best
way to handle input errors so maybe I need to imitate the better
approaches. If someone could point me to examples of good input error
handling, maybe I could finally see how I'm supposed to be doing it....
--
Rhino
Tom Anderson
> On 25-05-2010 01:05, Patricia Shanahan wrote:
Ah, whereas i'm just the opposite. It's easy to lose a return value. It's
hard to lose an exception.
tom
--
uk.local groups TO BE RENAMED uk.lunatic.fringe groups
Patricia Shanahan
Also, I prefer to reserve the return value for the primary result of the
method, the value it will produce if everything goes right. For
conversion methods, that is the result of a successful conversion.
Although in many cases one could use e.g. null to indicate an error,
that does not provide a good way of passing back the explanation of what
went wrong.
Patricia
David Lamb
> Also, is there much need for systems in which the user can switch
> languages on the fly?
Yes, if only for testing. You don't want to have to exit the program,
change locale, and re-run it to verify that your other-language text
comes out OK.
Rhino
@news.sunsite.dk:
> On 25-05-2010 14:57, Rhino wrote:
>> But I'd like to try to sum up a bit now. The conversation has gotten
>> sufficiently fragmented that I'm not sure what we would all agree on
>> with regards to the situation I am trying to resolve.
>
>> However, I find myself seriously doubting that Locale SHOULD be a
>> class variable after all. And if my reasoning is sound, which I hope
>> you will tell me, I may be able to go back to having all the methods
>> be static.
>>
>> As I look at the classes in the Java API, only a tiny handful of them
>> have constructors that take a Locale as an argument and only a tiny
>> handful have setLocale methods. Assuming that the Java API is
>> considered well-designed by the Java community - and I have to hope it
>> is :-) - that tells me that the remaining 99.9% of classes are
>> expecting to provide any locale-specific information in only ONE
>> Locale.
>
> Note that the Java API is a low level API and localization is
> most relevant for higher level business app code.
>
> The huge majority of Java API classes does not have any
> need for localization at all.
>
Good point.
>
>> Furthermore, no class invoking the API is typically going to
>> want to get the information in more than one language at a go.
>> Essentially, the classes operate on the basis of the Locale defined by
>> the user.country and user.language properties. Therefore, if my
>> properties are set to English and Canada, that is the locale that the
>> JVM is going to try to find - of course it will settle for other
>> flavours of English if there is no specific en_CA resource bundle -
>> and use for any other locale-specific text. (DateFormats,
>> NumberFormats, and their kin handle the localization needs of those
>> special kinds of data.)
>>
>> Providing a way to set a specific Locale and even to change that
>> Locale on the fly so that classes could potentially invoke the class
>> repeatedly for different Locales is simply overbuilding and is almost
>> certainly not necessary at all! (I say 'almost' in deference to Lew's
>> observations about there being no hard and fast rules, which makes a
>> lot of sense to me.) So I think I can dispose of Locale in
>> constructors (and their associated getInstance() methods altogether.
>> Likewise, I can omit and setLocale() and/or getLocale() methods from
>> my utility classes too. Methods that seek to get ResourceBundles will
>> simply seek them for the default Locale, as determined via
>> Locale.getDefault().
>
> That strategy may work OK for fat client apps. It will not work
> well for the server side code in web apps.
>
So where does it leave me with my utility classes? Some of the methods in
these classes are just convenience methods and others do smallish tasks
like counting the number of occurrences of a given character in a string.
It's certainly possible that some will get bad input and that they will
correspondingly need to handle them some way. Should I be giving users of
these classes the ability to specify a non-default locale and/or switch to
a different locale on the fly?
If not, I'm inclined to just let them work with the default locale and
retrofit additional constructors and/or getLocale()/setLocale() later if
the need arises....
--
Rhino
Arne Vajhøj
I am just reluctant to rely too much on the message of an Exception.
I prefer to rely on the type of the Exception.
Arne
Patricia Shanahan
I'm particularly dubious about this in connection with
internationalization, because in some cases logging should be in the
developers' working language, but GUI display in a language chosen by
the end user. The same Exception might trigger either or both.
>
> I prefer to rely on the type of the Exception.
Also remember that you can add your own fields to an Exception subclass.
I don't know whether this makes sense, but for a String conversion
exception it might be helpful to include the index in the String of the
first error. I'm not sure whether it would ever make sense to add an
enum for more detailed classification - one could always subclass instead.
Patricia
Arne Vajhøj
SQLException has a getErrorCode.
But then the original design of only having SQLException class
was a rather big mistake. Which they tried to fix in 1.6.
Arne
Tom Anderson
> Arne Vajh?j wrote:
>> On 26-05-2010 14:54, Rhino wrote:
>>> Arne Vajh?j<ar...@vajhoej.dk> wrote in
>>> news:4bfc7690$0$278$1472...@news.sunsite.dk:
>>>
>>>> On 25-05-2010 12:02, Rhino wrote:
>>>>> Arne Vajh?j<ar...@vajhoej.dk> wrote in
>>>>>
>>>>>> In most cases I don't think the exception text would
>>>>>> tell the end user anything.
>>>>>>
>>>>>> Of course there are cases where the message text from the
>>>>>> exception can be used in the end user error text. Just don't
>>>>>> display class names, stack traces etc..
>>>>>
>>>>> I don't log any of this and certainly don't show the user anything
>>>>> like a stacktrace; just the message from the ResourceBundle.
>>>>
>>>> A possible alternative could be to throw a custom exception
>>>> NotHexColorStringException and let the exception handling
>>>> code read the localized text.
>>
>> I am just reluctant to rely too much on the message of an Exception.
>
> I'm particularly dubious about this in connection with
> internationalization, because in some cases logging should be in the
> developers' working language, but GUI display in a language chosen by
> the end user. The same Exception might trigger either or both.
Which is precisely the problem the optionally self-localising exception
class i posted solves:
http://groups.google.com/group/comp.lang.java.programmer/msg/d0a0eb4ea84f3983
tom
--
Kein Mehrheit Fur Die Mitleid
Jim Janney
> Lew wrote:
>> Arne Vajhøj wrote:
>>>> And my guess is that Tom [sic] meant US English.
>>
>> Tom Anderson wrote:
>>> Certainly not! en_GB is the canonical form, and en_US is merely a
>>> popular but subordinate deviation.
>>
>> It has ever amazed me how well the Brits speak English. Awesome!
>
> Some of them even write it well, though rarely as well as the Irish.
"The Gibbelins eat, as is well known, nothing less good than man...."
--
Jim Janney
Gunter Herrmann
Rhino wrote:
> Sorry for the off-topic digression but I just can't help but admit to
> some surprise that some eastern Europeans still know German. Stalin and
> his eastern European brothers were pretty ruthless about exiling or
> killing their German residents in the immediate aftermath of WW II. I had
> thought the German language was pretty much non-existent in the former
> Warsaw Pact area by this point.... Based on what you're saying, it
> appears that I was premature in assuming an absence of German in those
> countries.
The presence of native speakers of the German language in Europe has
changed a bit quite recently.
When I was in the Central Asian parts of the former Soviet Union in 1986
there was a significant German minority, there even were newspapers and
some hours of radio program in German.
Romania had a lot of cities and villages where German was the majority
language.
But since then a lot of these people left for Germany in hope of a
better living.
Another thing is science in smaller countries (e.g. Hungary). Not a lot
of for instance medical literature is published in Hungarian. They use
books in German and English.
Best regards
Gunter
(a German in the US of A)
Mike Schilling
> Best regards
>
> Gunter
> (a German in the US of A)
Even further OT: Is "Best regards" a translation of a common German
closing. The people I've seen use it in e-mail are all Germans.
Andreas Leitgeb
There is no exact German pendant of the word "regards" for this context.
The nearest one would be "Grüße" (greetings), which in German may get
a "beste" (best) added (for extra emphasis). So, "best" also gets added
to regards...
Lew
>> Even further OT: Is "Best regards" a translation of a common German
>> closing. The people I've seen use it in e-mail are all Germans.
It used to be quite a common English closing, but perhaps it's not so common
now. I never noticed in my random samples that those who used it were of one
or another ethnic background particularly.
Andreas Leitgeb wrote:
> There is no exact German pendant of the word "regards" for this context.
> The nearest one would be "Grüße" (greetings), which in German may get
> a "beste" (best) added (for extra emphasis). So, "best" also gets added
> to regards...
--
Lew
Mike Schilling
> Mike Schilling wrote:
>>> Even further OT: Is "Best regards" a translation of a common German
>>> closing. The people I've seen use it in e-mail are all Germans.
>
> It used to be quite a common English closing, but perhaps it's not so
> common now. I never noticed in my random samples that those who used
> it were of one or another ethnic background particularly.
I often see regards, warm regards, or kind regards. "Best" not so much.