2009/8/30 Enrico Tröger enrico.troeger@uvena.de:
On Sat, 29 Aug 2009 21:40:01 +1000, Lex wrote:
2009/8/29 Enrico Tröger enrico.troeger@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@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel