I like that approach. I opened an issue to look into it how I can incorporate those ideas into my library. Who knows, though, Jakob might just beat me to it.
Thanks, Ryan Dew On Thu, Feb 21, 2013 at 7:18 AM, Florent Georges <[email protected]> wrote: > Ryan Dew wrote: > > > Those are interesting enhancements. I don't think it would be > > hard at all to extend it to support injection of numbers or > > words. Simply have the map entry contain an additional element > > that ties itself to a position in a sequence of items passed > > and replace it appropriately. > > The problem is that the position itself could be dependent on > the locale :-) > > > To be honest, I have no idea how I would address singular/ > > plural forms. It seems like that would have to be handled > > externally and the bundle would just need separate keys in a > > bundle for singular and plural forms. If you have any > > suggestions, I would love to here them. > > The approach I used a few years ago (God, that was in 2005 > actually, time's flying :-P) is described succently there: > > http://xsl.markmail.org/thread/zg4irqyap5begxmc > > Basically it uses XML to express a kind of format string, > instead of simple strings, and use elements as placeholders. It > also had more sophisticated features for some domain-specific > formatting, like formating a "person" using a format string, to > have different address or name formatting. But the general idea > is something like: > > <i18n xml:lang="en"> > <l10n key="some.key">The amount is <amount/>.</l10n> > </i18n> > <i18n xml:lang="fr"> > <l10n key="some.key">Le montant est <amount/>.</l10n> > </i18n> > > The place where the text must appear (the "caller") must > provide a value for the place holder. This value can itself be > locale-dependent (e.g. different numbers formating, in EN you use > "." as the decimal point and in FR we use ","). This example is > very simple and could be resolved by using simple strings and by > having the caller assembling them, but in some cases if you have > 2 variable parts A and B, in one language you will have part A > appearing before B and in another language B appearing before A. > With such a "template" format each localization can reorganize > itself the variable parts. > > For variable parts that are themselves dependent on some > dynamic values, the part can be a sort of a map: > > <i18n xml:lang="en"> > <l10n key="...">The book contains <number/> > <sections sg="section" pl="sections"/>.</l10n> > </i18n> > <i18n xml:lang="fr"> > <l10n key="...">Le livre contient <number/> > <sections sg="section" pl="sections"/>.</l10n> > </i18n> > > The caller has to define that he'll pass a value for "number" > (most likely a number) and a value for "sections" (either "sg" or > "pl" to select the singular or plural form). The result is a > more-or-less readable sentence with elements for variable parts. > > This is just my recollection after several years, and the > solution is probably not perfect, but it gives more flexibility > to people localizing the keys, and developers internationalizing > just have to define the different keys and the name of the > variable parts if any. > > Regards, > > -- > Florent Georges > http://fgeorges.org/ > http://h2oconsulting.be/ >
_______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
