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

Subject: Re: [boost] Boost.Locale and the standard "message" facet
From: Steve Bush (sb2_at_[hidden])
Date: 2011-05-05 05:40:39

> Now I hope it is clear now? A constant keys
> just create additional indirection level.
> 

Am well aware how it works but the problem is that you don’t seem to be aware of any limitations in the process.

1. You are hard coding stuff which can henceforth NEVER be changed (since it is the primary key into the translation data...base) despite the fact that it SOMETIMES it benefits considerably from being changed - for clarity.

2. Your binary is bloated with text

These are NOT the only limitations but they are perhaps the most clear.

I think it is quite ironic that you hate hard coding meaningless keys (eg integers) for messages, despite the fact that they are meaningless numbers that NEVER change, but are quite happy to hard code text strings which SOMETIME benefits from being changed.

The appeal of the gettext is its self-documentation BUT this has to be balanced versus problems 1 and 2 above and I think it is abundantly clear that gettext/translate using long text keys is NOT ALWAYS the correct solution.

> So, Never-Never-Never-Never-Never use artificial keys
> unless you want to make really bad software and make
> your software and translation teams miserable
> 

This reminds me of "irrational exhuberance"

> This is not theoretical question about some general
> databases foregin keys, it is very progmatic question
> about how to make the localization right.
> 

It isn't a theoretical issue at all since the translation data is a database and the message id is a primary key. The principle of DON’T USE MEANINGFUL PRIMARY KEYS IF THEIR MEANING MAY CHANGE is definitely applicable here.

The gettext/translate method is condemned to stick for ALL TIME with whatever stupid text the programmer considered was worthy at the initial coding!

It is notorious that concepts change over time and therefore HARD CODING TRANSLATION KEYS IS NOT A PERFECT SOLUTION IN ALL CASES.

The above problems are not an issue in many cases.

1. Some people don’t care that their translation keys CANNOT CHANGE EVER.

2. Some people don't care that their binaries are bloated with text

For those people gettext/translate is GREAT!

Just appreciate that there ARE some difficulties with HARD CODING CONSTANT STRINGS in at least some cases and recognise that every solution has its compromises.

> And yes in early age of software localization
> the integer keys could seen as good method,
> but nobody works this way today.
> 

I dunno Artyom, localisation has a very long history. It isn't something new you know. Meaningless keys for translation are the majority solution in Windows world and are not on the way out at all.

You should know that gettext was a quick and dirty hack to start with. All we had to do was wrap all or most strings with a function call and, at first run time, the program wrote out any newly discovered "localised" strings to a database and b) converted them wherever a translation could be found. AMAZING! But it DOES have its limitations!

> Artyom Beilis
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost