Re: [boost] Boost.Locale and the standard "message" facet

Subject: Re: [boost] Boost.Locale and the standard "message" facet
From: Vicente BOTET (vicente.botet_at_[hidden])
Date: 2011-05-02 04:16:09

Hi,

> Message du 30/04/11 15:48
> De : "Artyom" 
> A : boost_at_[hidden]
> Copie à : 
> Objet : Re: [boost] Boost.Locale and the standard "message" facet
> 
> > Subject: [boost] Boost.Locale and the standard "message" facet
> > 
> > Hi,
> > 
> > I was wondering how Boost.Locale is related
> >Â to the standard message facet which is used
> >Â to translate messages. 
> 
> 
> The standard message catalogs allow to extract
> messages by integer identifiers but may use string
> identifiers and it is implementation defined
> 
> It is undefined how to load message facets

Well implementation defined doesn't mean undefined.

> or format them and so on.

The formatting can always be done on top of this facet, isn't it?

> It does not support plural forms and context.

I'm not an expert, but doesn't catalogs and the set parameter can be used for your domain an context?

Respect to plural forms, how Boost.Locale manages with locales that have 3 or 4 forms of plurals (If I understood your private mail, Hebrew is an example of this)? I've the impression that Boost.Locale manage simple plurals but not all kind of plurals? BTW, what is the criteria in Boost.Locale to identify a plural form? 

How your library manage plurals for message that have several parameters? For example

translate("%1 hours, %2 minutes, %3 seconds") % h % m % s

> It is the most unless facet around.

What do you mean? That the scope is reduced?

> > Note that the facet
> >Â interface work with integer identifiers
> >Â avoiding all the issues raised by the
> >Â get_text/translate functions
> >Â provided by Boost.Locale.
> >
> 
> Use of integer identifiers is the best
> way to screw the localization in the software.
> 
> What does 3456 means? Do you really think
> it is good to write translate(MY_MESSAGE_OPENING_FILE)

Why not? 
Note that we can also write translate(MyMessage::OpeningFile) if this seems clearer to you

> No, never - never - never - never - never
> use such "constant" or "integer" identifiers.

I understand that some as you can find that the use of integers scale worst than the use of strings as we need to maintain constants unique on a given context, but this can be checked on debug mode.

Some time ago when I had to write a localization application, we used integer identifier to log internationalizable messages. This reduced drastically the size of the log. I guess only this advantage was enough to take integers instead of strings, for us of course. 

An advantage I see is that you need to concentrate all the message id of a set/context in a single file so no need to have tools that parse your code to get the strings to translate.

BTW, how do you recover message translation from a domain with your underlying implementation, copy/paste or is there a possibility to have specific files for specific domains, or there is a single translation file by locale?

I've not take a look at your implementation yet. Please could you tell me when the translation file is read? Is the file parsed only once and the translations stored on a cache?

> Always use natural text.

I think your natural language interface lets the user to have the impression that anything is possible, when a lot of limitations seem to be there as other have already commented in this ML. 
 
> > Is there any reason Boost.Locale
> >Â could not follow the standard design?
> 
> The standard message catalogs to weak

I would like to here the rationale of the standard message design by someone that is aware of it (some pointers will be welcome also).

> >Â What are the advantages of the Boost.Locale design?
> >
> 
> 1. Defined way to load and format catalogs

You could provide a defined way on top of this facet, isn't it?

> 2. Support of pural forms

Plural forms can be designed on top of the message facet?

> 3. Support of message-context

As I said, I suspect that the set parameter is interpreted as your context.

> 4. Using natural language identifiers as keys

See below. This is not always an advantage, and as far as I see adds some constraints on the interface so the tool can take care to automatically extract the strings to translate.

> 5. Convenense interface
What do you mean?
Could you compare both?

> More?

Well, I think that it would be great if you can add a complete comparison of the interfaces and a rationale why you think your design is superior on the documentation.

Best,
Vicente