Page 3 of 3

Posted: Wed Feb 07, 2007 10:35 pm
by Christopher
I think part of what frameworks like ZF are trying to do is make appropriate classes Locale aware. They have a default, but you can pass a Locale object to them and they will use the pertinent conventions of the Locale.

Posted: Wed Feb 07, 2007 10:53 pm
by Ambush Commander
I think what I'm seeing here is two distinct APIs for I18N application.

The "parameter" API, adopted by Zend Framework, is founded on the notion that the locale is simply another parameter in a certain class of functions. This makes localization a periphery issue: you could still use the function with, say, "EN" hard-coded in, it just wouldn't be I18N. Internally speaking, the function may implement all languages' functionality (definitely messy) or delegate to another object. But if you delegate everything, you get...

The "locale" API, in which the Locale object goes from being a simple identifier of the language to a fully fledged container/factory object for all pertinent information of the locale. The locale object need not actually have all the info, but it knows where to get the goodies. In many cases, non-localisable behavior can be abstracted back to the function, for our number formatting case, that would be the NumberFormatter, but Locale still is responsible (through composition or something) about NumberPattern, which is locale-dependent.

Perhaps I'm making a straw-man. The "parameter" API seems to be the favored method of actually interfacing with the localization facilities, while the "locale" API makes the most sense in terms of internal implementation. Personally, I'd use polymorphism to get rid of that extra parameter, making sure the NumberFormatter already is loaded with the locale I want, but the other approach is workable, sometimes necessary if you have multiple languages in one request.

Posted: Wed Feb 07, 2007 11:02 pm
by wei
I would question why would the formatter need to know about locale? date and number formatting are complicated enough by itself.

Also, the Common Locale Data Repository (CLDR) project already defines many common date and number patterns. So, i have assume that

Code: Select all

$pattern = $locale->getCurrencyPattern()
returns the appropriately defined pattern by the CLDR project.
Perhaps I'm making a straw-man. The "parameter" API seems to be the favored method of actually interfacing with the localization facilities, while the "locale" API makes the most sense in terms of internal implementation. Personally, I'd use polymorphism to get rid of that extra parameter, making sure the NumberFormatter already is loaded with the locale I want, but the other approach is workable, sometimes necessary if you have multiple languages in one request.
the implementation and the user interface are related but have different design decisions. Thus, it may be user friendly to provide a simpler interface (e.g. the "parameter" version), and let the implementation be decoupled for easier testing.

Posted: Wed Feb 07, 2007 11:11 pm
by Christopher
wei wrote:I would question why would the formatter need to know about locale? date and number formatting are complicated enough by itself.
For me it is the reverse. Locale knows what currency and separator symbols are, but doesn't know how to format numbers. The Formatter knows how to format numbers, and will do it with whatever currency and separator symbols you provide. The Locale object just give a standard interface to get such symbols.

Posted: Wed Feb 07, 2007 11:21 pm
by wei
the $pattern is not a string, it contains the so said separators and positions. Apologies for leaving out the details..

Posted: Wed Feb 07, 2007 11:24 pm
by Ambush Commander
Therefore we are actually all in agreement on the matter. :-)

arborint, I'm curious. What would you do if you had a behavior that needed to be localized, but the only way to do it was implement a separate function for each language (example: grammatical transformations). Would that go in the Locale object?

Posted: Thu Feb 08, 2007 12:21 am
by wei
ask the locale for the grammar rules ;) are you planning to build an automated natural language translator or something....
otherwise handling the pluralization of certain languages in the translation text itself may be sufficient

Posted: Thu Feb 08, 2007 12:30 am
by Christopher
Ambush Commander wrote:arborint, I'm curious. What would you do if you had a behavior that needed to be localized, but the only way to do it was implement a separate function for each language (example: grammatical transformations). Would that go in the Locale object?
Well the assumption is, using wei's example, that the Locale class is going to somehow delegate to a Locale_En_Au class somewhere. But if, as you suggest, there are then implementation differences then those differences (preferably) need to be somehow discoverable so they can actually be used -- or worked around if they are not present.

Posted: Thu Feb 08, 2007 4:17 am
by Jenk
Sorry for the delayed response, yes my example contains a settings object - an implementation of the Settings Object pattern.

Posted: Thu Feb 08, 2007 1:22 pm
by Ambush Commander
ask the locale for the grammar rules ;-) are you planning to build an automated natural language translator or something....
otherwise handling the pluralization of certain languages in the translation text itself may be sufficient
You'd be surprised. Stuff like this happens when a language has lots of different tenses and moods for nouns. The site name, for instance, would have to be displayed in a different form when displayed in different contexts.

Pluralization definitely is a more common case, and I suppose can be done directly in the message, although I have yet to see a readable but compact syntax for doing so.
Well the assumption is, using wei's example, that the Locale class is going to somehow delegate to a Locale_En_Au class somewhere. But if, as you suggest, there are then implementation differences then those differences (preferably) need to be somehow discoverable so they can actually be used -- or worked around if they are not present.
So the Locale class isn't actually an instance Locale_En_Au hmm... (I think this is how Java behaves) I'm not sure what you mean by the second part.
Sorry for the delayed response, yes my example contains a settings object - an implementation of the Settings Object pattern.
Okay. So what does "// properties file of EN.Warning="Warning" or database or whatever. " mean? I'm inclined to believe i18n-izable system messages are not to be conflated with system settings, even though both should, ideally, be customizable.

Posted: Thu Feb 08, 2007 2:06 pm
by Christopher
Ambush Commander wrote:I'm not sure what you mean by the second part.
Well ... if you have a standard API and then various extensions then you need an API to discover what extensions exist.

Posted: Thu Feb 08, 2007 3:29 pm
by Ambush Commander
But if, as you suggest, there are then implementation differences then those differences (preferably) need to be somehow discoverable so they can actually be used -- or worked around if they are not present.

Well ... if you have a standard API and then various extensions then you need an API to discover what extensions exist.
Ahh, I see what you're saying. I'd probably just have a base, do-nothing, not-too-dangerous generic implementation and overload it in the subclassed Locale. No need for fancy API detection.

Posted: Thu Feb 08, 2007 4:48 pm
by wei
Ambush Commander wrote: You'd be surprised. Stuff like this happens when a language has lots of different tenses and moods for nouns. The site name, for instance, would have to be displayed in a different form when displayed in different contexts.
I think there is a limit to how much you can delegate the localization to message translations or other localization methods. If the app/site need to be able to localize based on context, then it may be better to have a separate sub-site. E.g. it may be more suitable to have a sub-site that accomodates for right-to-left layouts such as arabic.

Posted: Thu Feb 08, 2007 8:57 pm
by Ambush Commander
I really think it can work without requiring a fork of page code. Wikipedia's done it.

Posted: Fri Feb 09, 2007 4:59 am
by Jenk
a Java Properties file (similar to an INI file) or a Database with tables containing the messages and so forth. Merely examples of a datalayer.

I couldn't tell you what i18n is until I read this thread, let alone if any of that conforms :P