Are messages part of a language

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post 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.
(#10850)
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post 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.
wei
Forum Contributor
Posts: 140
Joined: Wed Jul 12, 2006 12:18 am

Post 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.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post 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.
(#10850)
wei
Forum Contributor
Posts: 140
Joined: Wed Jul 12, 2006 12:18 am

Post by wei »

the $pattern is not a string, it contains the so said separators and positions. Apologies for leaving out the details..
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post 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?
wei
Forum Contributor
Posts: 140
Joined: Wed Jul 12, 2006 12:18 am

Post 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
Last edited by wei on Thu Feb 08, 2007 12:34 am, edited 1 time in total.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post 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.
(#10850)
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post by Jenk »

Sorry for the delayed response, yes my example contains a settings object - an implementation of the Settings Object pattern.
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post 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.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post 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.
(#10850)
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post 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.
wei
Forum Contributor
Posts: 140
Joined: Wed Jul 12, 2006 12:18 am

Post 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.
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

I really think it can work without requiring a fork of page code. Wikipedia's done it.
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post 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
Post Reply