Page 2 of 3

Posted: Wed Feb 07, 2007 3:40 pm
by Jenk
It all depends on your data layer it would seem.

Code: Select all

<?php

$localeSettings = new Settings(/* data source */); // properties file of EN.Warning="Warning" or database or whatever.

$local = new Locale($localeSettings);

$messages = new Messages($localeSettings);

?>

Posted: Wed Feb 07, 2007 3:45 pm
by daedalus__
I've been following this thread and wanted to say a lot at different times but figured it would sound stupid. I can, however, reply to this statement :D:
Ambush Commander wrote:An object, then, for each currency. Presumably, the same would have to apply to dates, number formatting, etc. Inheritance used to prevent duplication. Which is a lot of objects!
Objects are a good thing, while it would be a ton of objects, I think it is okay to have them. Even if it would not have an effect on the maintainability/scalability/portability/randombility of the application, it is still practice. If you are programming OO code, everything should be an object, right?

Posted: Wed Feb 07, 2007 4:04 pm
by Ambush Commander
It all depends on your data layer it would seem.
Hmm... not sure what's going on in your code. Is Settings a generic configuration object?
Objects are a good thing, while it would be a ton of objects, I think it is okay to have them. Even if it would not have an effect on the maintainability/scalability/portability/randombility of the application, it is still practice. If you are programming OO code, everything should be an object, right?
Yes, lots of objects are good! :-)

What I'm wondering, however, is how we should define the relationships between the objects. If you use dateFormat($time, $locale), the monkeying around with objects happens in the background, so the objects are not so much for flexibility as for partitioning of different segments of code.

It just struck me, what if we used:

Code: Select all

$locale = new Locale('en');
$m = $locale->getMessages();
echo $m->get('message-identifier');

$n = $locale->getNumberFormatter();
echo $n->format(83242833);

// etc
Rather than pass locale to the localization object, have locale retrieve the localization object for you. If you have a segment of functionality that doesn't seem to merit it's own object, you can stuff it in locale temporarily, and then factor it into its own object, maintaining the old functions for backwards-compatibility for a few versions.

Does this sound like a good idea? (because if so, I've got another question about the nature of $m)

Posted: Wed Feb 07, 2007 4:41 pm
by wei
I prefer

Code: Select all

$locale = new Locale('en_AU');
$pattern = $locale->getCurrencyPattern();
$nf = new NumberFormatter();
echo $nf->format(12.0, $pattern); //may use custom pattern
where the $pattern object contains information such as decimal points, symbols, separators, etc.
This separates locale from the number/date/measure formatters

how ever the MessageFormatter is a little different, because it needs to know about the message sources

Code: Select all

$source = new MessageSource(); //or more specific sources
$bundle = $source->getBundle('bundle1', $locale);
$mf = new MessageFormatter($source);
$mf->addBundle($bundle);
$result = $mf->format($message, $subsititutes);

$choice = new ChoiceFormatter();
echo $choice->format($result);

Posted: Wed Feb 07, 2007 4:45 pm
by Ambush Commander
Your point about the number formatter is well taken. Where does Locale fit into MessageFormatter though?

Posted: Wed Feb 07, 2007 4:47 pm
by wei
It doesn't, the message formatter is not aware of locales, only about sources and that the source can be called on to retrieve fallback bundles.

Posted: Wed Feb 07, 2007 4:48 pm
by Ambush Commander
So locale determines which message bundles to get?

Posted: Wed Feb 07, 2007 4:51 pm
by wei
I say so, formatter just formats and may call on the source to get more bundles, the source takes care of fetching the appropriate bundle (may depend on locale).

Posted: Wed Feb 07, 2007 4:53 pm
by Ambush Commander
That makes a lot of sense. I like. Anyone else have any comments?

Posted: Wed Feb 07, 2007 5:02 pm
by wei
of course you can always provide helper methods or a fascade to simplify the usage. e.g.

Code: Select all

function format_message($msg, $subs, $locale);
function format_currency($value, $locale);
function format_decimal($value, $locale);
function format_xxx()

Posted: Wed Feb 07, 2007 8:06 pm
by Ambush Commander
Well, the trouble with that is I still have to namespace all of them, so it's not terribly useful in my case. Fully-fledged apps, sure (just make sure code doesn't sneak its way into the global functions).

Posted: Wed Feb 07, 2007 10:20 pm
by alex.barylski
Ambush Commander wrote:Right. Your system focuses solely on message substitution and not other localization related functions. As for modular language files, I don't think splitting them up will be necessary for my purposes (there shouldn't be that many).
Other locale settings? You mean like date formatting?

I usually store a string for that inside user profiles...I'm not even sure what Canadians use officially whether it's MM/DD/YYYY or DD/MM/YYYY but personally I always use the first.

Posted: Wed Feb 07, 2007 10:22 pm
by Ambush Commander
Right. You store the date in a application-wide format that retains the most information. When you output it, however, you want to format it for whatever the locale is. If the user is Chinese, format it Chinese-style, if the user is British, format it British-style. You may even want to let them specify their own format.

Posted: Wed Feb 07, 2007 10:28 pm
by Christopher
wei wrote:I prefer

Code: Select all

$locale = new Locale('en_AU');
$pattern = $locale->getCurrencyPattern();
$nf = new NumberFormatter();
echo $nf->format(12.0, $pattern); //may use custom pattern
This seems like $pattern becomes a dangling external dependency of both classes. Would something more direct be better?

Code: Select all

$locale = new Locale('en_AU');
$nf = new NumberFormatter($locale);
echo $nf->formatCurrency(12.0);

Posted: Wed Feb 07, 2007 10:31 pm
by Ambush Commander
This seems like $pattern becomes a dangling external dependency of both classes. Would something more direct be better?
Yes, but it's a bit vague based on the code. Does $locale contain $pattern or is it $nf?