Contribution: Translating into spanish

Dirk Hohndel dirk at
Tue Oct 9 16:25:47 PDT 2012

"Lubomir I. Ivanov" <neolit123 at> writes:

> ouch,
> i'm new to this...
> string matching for string retrieval, probably without cashing for any
> sorts on each call.
> i'm sorry, but if that is what drives gnome no wonder the sluggishness
> on 10y/o machines...:(
> even with a smart dictionary algorithm i don't think this is an
> efficient method...especially for smaller apps.
> a vastly superior method is string matching for string retrieval only
> once i.e at memory allocation - post a parser stage.
> but some of that in fact is redundant given there is already usage of
> libxml in the application.
> then a global "language" struct holding hardcoded list of pointers to
> string data, which gives the form:
> language.dialogs.some_dialog_string
> vs
> gettext("some dialog string from a dictionary with 1000 strings")

The tradeof here is maybe a tiny performance hit at runtime versus using
the best supported toolset to do cross-OS localization. Given the
limited research that I have done into the issue, it seems that gettext
is actually well understood and well supported with nice tooling around
it for the translators.

Unless you have another specific open source library that can match that
and also gives us the performance improvements that you so rightfully
point out could be obtained... I don't think I am willing for us to
spend time on writing our own localization tools...

> instead of XML a majority of windows applications use the INI format
> (which is slightly faster to parse), a bit linear yet absolutely fine
> for this:
> [section1]
> some_key=some_value
> ...
> [section2]
> some_key=some_value2
> then after loading the Windows API gives GetPrivateProfileString(),
> which writes to a user buffer and lets _him_ pass pointers around.

That's nice - again, how would this integrate with the build tools that
we use, where is the upstream open source implementation?

> also i'm not sure if this call is crucial for gettext to work:
> setlocale( LC_ALL, "" );
> but i recall that it was unwanted at some point due to GTK issues,
> could be wrong.

I believe we have fixed the Gtk issue - Linus, you were working on that,
do you remember what exactly happened there?


More information about the subsurface mailing list