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

Subject: Re: [boost] Boost.Locale and the standard "message" facet
From: Artyom (artyomtnk_at_[hidden])
Date: 2011-05-05 09:24:18

> > 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.
> 

First of all if the original string is changed then you also
must revisit the translation string, in this case the 
"key" = "original" text is very important.

And if the change is relatively small 
it would be marked as fuzzy and translator would
be able to see if he needs to keep current translation
or update it.

> 2. Your binary is bloated with text
> 

Really?

Have you ever did any measurements?

For example gtranslator - a GUI program written in C that
is used for work with po/mo gettext files.

Symbols in ELF: 36577 bytes
Translation keys: 10324 bytes!

And this is C! Now support or RTTI and class names
of all templates, all symbols are very small not like
the symbols of STL that can take several K of text
to mangle them and so on.

Texts are small. Really, there is no bloat
in putting texts into executables.

>[snip]
> 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.
> 

Nobody uses today integers, even Java and .Net use 
some textual identifiers and never numbers.

It just does not work well.

And of course Boost.Locale allows you to use arbitrary
text as key... 

You can write translate("menu.file.title") without
problems if you really want to...

But it is not recommended.

> [snip]
>
> You should  know that gettext was a quick and dirty hack to start with.

It is not "hack", because other localization systems
like Qt uses same concept, and they know a things or two
in UI development:

  http://doc.qt.nokia.com/4.6/internationalization.html

Please, before anybody suggests
once again about using "integers" as keys...

Take a look on the current localization world...

LoadString and its POSIX friend catgets are
in the past.

Best,
  Artyom