[Geany-devel] intltool usage question

[Lex Trotman]

2009/8/30 Enrico Tröger <enrico.troeger at uvena.de>:
> On Sat, 29 Aug 2009 21:40:01 +1000, Lex wrote:
>
>>2009/8/29 Enrico Tröger <enrico.troeger at uvena.de>:
>>> On Sat, 29 Aug 2009 21:02:35 +1000, Lex wrote:
>>>
>>>>> I'm still not too happy about this as it adds some overhead for a
>>>>> rather small effort.
>>>>>
>>>>> I think Nick suggested this earlier:
>>>>>
>>>>> why don't we simply put the defaul labels somewhere into
>>>>> src/build.c so that intltool grabs them as usual. And then when
>>>>> reading the labels from the config file, we simply pass them
>>>>> through gettext() to get them translated automatically. If I don't
>>>>> miss anything obvious, this should have the same result but
>>>>> without the need for an external script. The only drawback with
>>>>> this effort is that we have the English labels itself twice (one
>>>>> in src/build.c, one in the config file) but since they probably
>>>>> won't change much at all it might be not such a big issue.
>>>>
>>
>>But you also have the overhead of every time the filetype file is
>>loaded, filetypes.c having to check for labels in the string list and
>
> filetype definition files are only loaded once per session. If not,
> that's a bug. Checking for translatable strings is quite fast, we won't
> do it ourselves but using gettext() which uses hashed versions of the
> strings for faster comparison, AFAIK. This is what is done for every
> single user visible string in the GUI already.
>

I wasn't clear enough, I wasn't talking about the gettext part of it,
I was talking about the filetypes file loader having to determine some
way that its label string is actually in the code (in case it  has
been user configured when it won't be), that it hasn't been changed
(which means having the original string as well as the gettext
version) and then it can use the gettext version.  None of it is
impossible, I guess I'm just annoyed that such a workaround is needed
:-( (which is a comment on intltool capabilities or documentation I
may have missed something but I have great trouble figuring it out).

>
>>load the translation but only for the system filetypes files since we
>>don't want this behavior on filetypes users have modified.  And of
>>course the system config file labels are now hard coded into the
>>program so system administrators can't configure using the
>>configuration files for site changes...
>
> No, the labels are not hardcoded, they are still in the filetype
> definitions. But they are *also* in the code, just as a lazy workaround
> to get them picked up by intltool. So, packagers or sysadmins or
> whoever can still modify the labels in the config files, of course with
> loosing the translation but this happens in either way.
>

True

>
>>If no solution that uses the current translation process can be found
>>then  maybe the best idea is just to ask users who want translated
>>labels to submit a patch or at least the translation and type it
>>manually into the filetype file, after all its only likely to be one
>>or two words to be translated like this:
>
> I said this in the very beginning of this discussion, IIRC. It's maybe
> not that important at all to have these few labels translated, at least
> not if it causes so much trouble and efforts. I guess it won't
> disturb most users that much and the others can easily change the
> labels in the build settings dialog, right?
>

Ok, you are right again :-) consider the subject forgotten.

>
>>FT_00_LB=Beer!!
>>FT_00_LB[de]=Bier!!
>>
>>Now thats the sort of menu item I'd like to see, and nearly the limit
>>of my German :-D
>
> Haha, quite important though. Being able to order a beer is always a
> good thing :).
>
>
> Regards,
> Enrico
>
> --
> Get my GPG key from http://www.uvena.de/pub.asc
>
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>
>