Are messages part of a language
Moderator: General Moderators
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
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.
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.
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
returns the appropriately defined pattern by the CLDR project.
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()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.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.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
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.wei wrote:I would question why would the formatter need to know about locale? date and number formatting are complicated enough by itself.
(#10850)
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
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?
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?
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
otherwise handling the pluralization of certain languages in the translation text itself may be sufficient
Last edited by wei on Thu Feb 08, 2007 12:34 am, edited 1 time in total.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
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.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?
(#10850)
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
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.ask the locale for the grammar rulesare 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
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.
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.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.
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.Sorry for the delayed response, yes my example contains a settings object - an implementation of the Settings Object pattern.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
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.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.
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.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.
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US