Contribution: Translating into spanish

[Lubomir I. Ivanov]

On 10 October 2012 02:25, Dirk Hohndel <dirk at hohndel.org> wrote:
> "Lubomir I. Ivanov" <neolit123 at gmail.com> 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...
>

ok, i understand.

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

here is a small, multiplatform library test (0.1 that is) for parsing
INI like files that i just wrote.
this is mostly a POC in plain ANSI C.

it covers the basics for something like UTF-8 language files:
- fast
- tiny footprint
- clean API
- elementary dictionary

i can easily add some sort of primitive caching algorithm.
no need to compile extra files like "gettext" to make it all work - it
can be used to simply load language file on runtime.

while this might be usable elsewhere i really don't wan't subsurface
to depend on something like that.
so yeah just a POC, but could be usable.

tested on windows 7 and ubuntu 12.04.

lubomir
--
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cfg2.zip
Type: application/zip
Size: 3343 bytes
Desc: not available
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20121010/2ab4daca/attachment.zip>