Hi All,
A question for the Geany translation/intltool expert.
I have been creating a Latex filetype file for the build-system branch which contains labels for the menu items which need translation, "View PDF File" and "View DVI File" for example.
The filetype is read in a locale sensitive manner and should load any translations that are in the file, and my reading of the intltool documentation leads me to believe that it should be able to extract marked entries from config files like filetype.latex and include them in the translation process alongside the source code strings and then merge the translations back into the config file.
What I can't work out from the documentation is how do I tell intltool to do it. I read it as it will include desktop.ini and other known files but it doesn't tell how to include other files. X-S
Can anyone help please.
Cheers Lex
On Tue, 14 Jul 2009 21:59:28 +1000, Lex wrote:
Hi All,
A question for the Geany translation/intltool expert.
Tell me if you found one :).
I have been creating a Latex filetype file for the build-system branch which contains labels for the menu items which need translation, "View PDF File" and "View DVI File" for example.
The filetype is read in a locale sensitive manner and should load any translations that are in the file, and my reading of the intltool documentation leads me to believe that it should be able to extract marked entries from config files like filetype.latex and include them in the translation process alongside the source code strings and then merge the translations back into the config file.
What I can't work out from the documentation is how do I tell intltool to do it. I read it as it will include desktop.ini and other known files but it doesn't tell how to include other files. X-S
See the geany.desktop.in file. This is exactly what you want: the .desktop.in file contains _Foo=Center entries. The leading underscore indicates that this string should be localised when processed with intltool. Intltool will recognise these entries and replace the value with found translations. The result would look like: Foo=Center Foo[en_GB]=Centre Foo[de]=Zentrum Foo[fr]=Centre ...
And GLib's keyfile parser can read these entries as well, i.e. it returns the value for the current locale when using the g_key_file_get_locale_string() function.
IIRC this all is part of the desktop entry spec at fd.o, but I might be wrong. Anyway, it works this way and we are using this in our .desktop.in file since ages. One more note about the .in: the raw file has the _Foo=... keys and then it get processed with intltool which replaces the underscore prefixed entries with the localised ones and so the file becomes .desktop.
In theory, we could apply this workflow to the filetype definition files to get localised build menu labels. But I don't really like this idea as it would mean we need to rename all these files and add rules to our both build systems to process each of these files with intltool.
I'd even rather prefer to have unlocalised English labels by default since the user can change them now as necessary though this isn't really nice too. A third possibility would be to list the necessary translatable strings for the labels in some source file like src/build.c so that the gettext translation system will pick them up by default and they get localised by the busy translators and then after reading the label texts from the filetype definition files, we feed them to gettext() to get the translation before displaying them. This would be probably the easiest way while it feels a bit hackish.
What do the others think?
Regards, Enrico
Hi Enrico,
Thanks see below.
And GLib's keyfile parser can read these entries as well, i.e. it returns the value for the current locale when using the g_key_file_get_locale_string() function.
my build-system branch build.c uses this for system filetype files to read menu labels
In theory, we could apply this workflow to the filetype definition files to get localised build menu labels. But I don't really like this idea as it would mean we need to rename all these files and add rules to our both build systems to process each of these files with intltool.
This workflow is what I was asking about, I have a filetype.latex.in with the appropriate key marked but intltool ignores it, is there something somewhere else that needs to be set to make it work?
Do we have to do it for all filetypes files or only those which need it (latex initially).
If only the required files need to be renamed then it could migrate over time as patches were submitted by individual language users and no big upheaval needed. Note that labels in the filetype file are only needed for filetypes where the default labels of compile, build and execute are inappropriate or which add extra commands.
The new settings are in a different section in the filetype file and the old filetype file settings are still read if no new section is found, I wasn't even going to change most of the filetypes files to the new format.
I'd even rather prefer to have unlocalised English labels by default since the user can change them now as necessary though this isn't really nice too.
Well this is what happens by default even if there are no translations. I only put the capability in the software because localised labels are nicer, but if it turns out to be *way* too much trouble then it will continue to work fine as is.
A third possibility would be to list the necessary translatable strings for the labels in some source file like src/build.c so that the gettext translation system will pick them up by default and they get localised by the busy translators and then after reading the label texts from the filetype definition files, we feed them to gettext() to get the translation before displaying them. This would be probably the easiest way while it feels a bit hackish.
Desperatly trying to avoid this :-(
What do the others think?
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
On Wed, 15 Jul 2009 11:27:42 +1000, Lex wrote:
(sorry for the delayed responses, I try to catch up all the other mails soon :( )
In theory, we could apply this workflow to the filetype definition files to get localised build menu labels. But I don't really like this idea as it would mean we need to rename all these files and add rules to our both build systems to process each of these files with intltool.
This workflow is what I was asking about, I have a filetype.latex.in with the appropriate key marked but intltool ignores it, is there something somewhere else that needs to be set to make it work?
Did you also add it to the build system to get it preprocessed by intltool? For waf it would be adding a new build task in the build() method, similar to what the task for geany.desktop.in looks like. I'm not how to do it with autotools but it's also possible as we also process the geany.desktop.in with intltool with autotools.
Do we have to do it for all filetypes files or only those which need it (latex initially).
If we really would go this way, it should be easy to only process these files which are necessary. But I don't like this at all.
If only the required files need to be renamed then it could migrate over time as patches were submitted by individual language users and no big upheaval needed. Note that labels in the filetype file are only needed for filetypes where the default labels of compile, build and execute are inappropriate or which add extra commands.
The new settings are in a different section in the filetype file and the old filetype file settings are still read if no new section is found, I wasn't even going to change most of the filetypes files to the new format.
I'd even rather prefer to have unlocalised English labels by default since the user can change them now as necessary though this isn't really nice too.
Well this is what happens by default even if there are no translations. I only put the capability in the software because localised labels are nicer, but if it turns out to be *way* too much trouble then it will continue to work fine as is.
I don't expect any noticeable troubles but I just don't like the idea of preprocessing these files much. It would end up in some filetype definition files with the .in extension, some without. Additionally, the build time increases and the code to maintain. These are all not strong arguments and I'm not completely against it, just want to mention I personally don't like it too much.
Regards, Enrico
2009/7/17 Enrico Tröger enrico.troeger@uvena.de
On Wed, 15 Jul 2009 11:27:42 +1000, Lex wrote:
(sorry for the delayed responses, I try to catch up all the other mails soon :( )
In theory, we could apply this workflow to the filetype definition files to get localised build menu labels. But I don't really like this idea as it would mean we need to rename all these files and add rules to our both build systems to process each of these files with intltool.
This workflow is what I was asking about, I have a filetype.latex.in with the appropriate key marked but intltool ignores it, is there something somewhere else that needs to be set to make it work?
Did you also add it to the build system to get it preprocessed by intltool? For waf it would be adding a new build task in the build() method, similar to what the task for geany.desktop.in looks like. I'm not how to do it with autotools but it's also possible as we also process the geany.desktop.in with intltool with autotools.
Will have a look later then, (my autotools aversion is well known ;-).
Do we have to do it for all filetypes files or only those which need it (latex initially).
If we really would go this way, it should be easy to only process these files which are necessary. But I don't like this at all.
If only the required files need to be renamed then it could migrate over time as patches were submitted by individual language users and no big upheaval needed. Note that labels in the filetype file are only needed for filetypes where the default labels of compile, build and execute are inappropriate or which add extra commands.
The new settings are in a different section in the filetype file and the old filetype file settings are still read if no new section is found, I wasn't even going to change most of the filetypes files to the new format.
I'd even rather prefer to have unlocalised English labels by default since the user can change them now as necessary though this isn't really nice too.
Well this is what happens by default even if there are no translations. I only put the capability in the software because localised labels are nicer, but if it turns out to be *way* too much trouble then it will continue to work fine as is.
I don't expect any noticeable troubles but I just don't like the idea of preprocessing these files much. It would end up in some filetype definition files with the .in extension, some without. Additionally, the build time increases and the code to maintain. These are all not strong arguments and I'm not completely against it, just want to mention I personally don't like it too much.
Well, I don't mind leaving it at English since thats what I use, but the
facility is there if there is an easy way of using it. As I said above I will have a quick look later on, but won't spend much time on it, help welcome.
Cheers Lex
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
On Fri, 17 Jul 2009 08:04:58 +1000, Lex wrote:
2009/7/17 Enrico Tröger enrico.troeger@uvena.de
On Wed, 15 Jul 2009 11:27:42 +1000, Lex wrote:
(sorry for the delayed responses, I try to catch up all the other mails soon :( )
In theory, we could apply this workflow to the filetype definition files to get localised build menu labels. But I don't really like this idea as it would mean we need to rename all these files and add rules to our both build systems to process each of these files with intltool.
This workflow is what I was asking about, I have a filetype.latex.in with the appropriate key marked but intltool ignores it, is there something somewhere else that needs to be set to make it work?
Did you also add it to the build system to get it preprocessed by intltool? For waf it would be adding a new build task in the build() method, similar to what the task for geany.desktop.in looks like. I'm not how to do it with autotools but it's also possible as we also process the geany.desktop.in with intltool with autotools.
Will have a look later then, (my autotools aversion is well known ;-).
Do we have to do it for all filetypes files or only those which need it (latex initially).
If we really would go this way, it should be easy to only process these files which are necessary. But I don't like this at all.
If only the required files need to be renamed then it could migrate over time as patches were submitted by individual language users and no big upheaval needed. Note that labels in the filetype file are only needed for filetypes where the default labels of compile, build and execute are inappropriate or which add extra commands.
The new settings are in a different section in the filetype file and the old filetype file settings are still read if no new section is found, I wasn't even going to change most of the filetypes files to the new format.
I'd even rather prefer to have unlocalised English labels by default since the user can change them now as necessary though this isn't really nice too.
Well this is what happens by default even if there are no translations. I only put the capability in the software because localised labels are nicer, but if it turns out to be *way* too much trouble then it will continue to work fine as is.
I don't expect any noticeable troubles but I just don't like the idea of preprocessing these files much. It would end up in some filetype definition files with the .in extension, some without. Additionally, the build time increases and the code to maintain. These are all not strong arguments and I'm not completely against it, just want to mention I personally don't like it too much.
Well, I don't mind leaving it at English since thats what I use, but the
facility is there if there is an easy way of using it. As I said above I will have a quick look later on, but won't spend much time on it, help welcome.
So, let's keep them in English for now. If I have time and am bored enough, I will have a look at some time. If your branch is finally merged and I didn't have had a look at this time, I forgot it :).
Regards, Enrico
On Fri, 17 Jul 2009 18:27:18 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
Well, I don't mind leaving it at English since thats what I use, but the
facility is there if there is an easy way of using it. As I said above I will have a quick look later on, but won't spend much time on it, help welcome.
So, let's keep them in English for now. If I have time and am bored enough, I will have a look at some time. If your branch is finally merged and I didn't have had a look at this time, I forgot it :).
I thought the default menu labels could still be in the source code, so would get translated. Not sure how easy it is to do now though ;-)
Regards, Nick
2009/8/25 Nick Treleaven nick.treleaven@btinternet.com:
On Fri, 17 Jul 2009 18:27:18 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
Well, I don't mind leaving it at English since thats what I use, but the
facility is there if there is an easy way of using it. As I said above I will have a quick look later on, but won't spend much time on it, help welcome.
So, let's keep them in English for now. If I have time and am bored enough, I will have a look at some time. If your branch is finally merged and I didn't have had a look at this time, I forgot it :).
I thought the default menu labels could still be in the source code, so would get translated. Not sure how easy it is to do now though ;-)
The "default" defaults are still in the code for exactly that reason :-)
IIRC this discussion was about filetypes that might want something other than compile or build by configuring something in their filetypes file.
The code should now load locale sensitive strings if they exist, its about how they get translated. Intltool is supposed to manage this by integrating config files into the translation process, but it seems to have a fixed list of filenames :-(
Cheers Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Tue, 25 Aug 2009 21:52:34 +1000 Lex Trotman elextr@gmail.com wrote:
I thought the default menu labels could still be in the source code, so would get translated. Not sure how easy it is to do now though ;-)
The "default" defaults are still in the code for exactly that reason :-)
IIRC this discussion was about filetypes that might want something other than compile or build by configuring something in their filetypes file.
Yes, but any default string could be added to the codebase for translations, not just compile and build. Assuming it's a 'general' kind of menu label, things which would be useful for several filetypes.
Regards, Nick
2009/8/26 Nick Treleaven nick.treleaven@btinternet.com:
Yes, but any default string could be added to the codebase for translations, not just compile and build. Assuming it's a 'general' kind of menu label, things which would be useful for several filetypes.
All the strings in the code that appear as labels should already be marked for translation, if I missed any thats a bug :-)
There isn't any way of changing the default label string to a different default depending on filetype. The intention is that if you want to change a filetype menu label it is configured in the filetypes file along with the command and overrides the default.
Let me look at a possible solution in a few days.
Cheers Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Hi Nick, Enrico, Frank,
As I understand it intltool handles config files by creating a C file with their strings that can be processed with the other code, and then updates the config files with the translations from the .po files.
Inspired by this here is a 50 line python script to do this for build menu entries in filetypes files.
run as: xbuildmenu.py mkc cfile list_of_filetypes_files..
it creates the file cfile as a C file with strings containing all the build menu labels it finds in the listed filetypes files (filetypes.* would be good:-) this cfile can be processed by your translation tools (tested with xgettext) along with all the other program files to extract strings for translation. A good name for cfile might be buildmenutranslate.h
run as: xbuildmenu.py upd cfile podir
it searches the po files in podir for strings taken from the cfile and using the information in the structured comments in the cfile copies the translation back into the filetypes files with a language marker the same as the po file name, eg de.po gives [de] on the config file entry.
It should be easy to call this from the waf script since you are guaranteed that python is available :-). We are only talking about the standard filetypes as delivered with the system so there is no need for users to run this, just run when translations are updated in svn.
It uses grep to speed its file search by eliminating lots of files (hopefully)
Cheers Lex
2009/8/26 Lex Trotman elextr@gmail.com:
2009/8/26 Nick Treleaven nick.treleaven@btinternet.com:
Yes, but any default string could be added to the codebase for translations, not just compile and build. Assuming it's a 'general' kind of menu label, things which would be useful for several filetypes.
All the strings in the code that appear as labels should already be marked for translation, if I missed any thats a bug :-)
There isn't any way of changing the default label string to a different default depending on filetype. The intention is that if you want to change a filetype menu label it is configured in the filetypes file along with the command and overrides the default.
Let me look at a possible solution in a few days.
Cheers Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Sorry guys, don't use it as is, the Python config parser removes comments from the config file, not what we want, back to the drawing board.
Cheers Lex
2009/8/28 Lex Trotman elextr@gmail.com:
Hi Nick, Enrico, Frank,
As I understand it intltool handles config files by creating a C file with their strings that can be processed with the other code, and then updates the config files with the translations from the .po files.
Inspired by this here is a 50 line python script to do this for build menu entries in filetypes files.
run as: xbuildmenu.py mkc cfile list_of_filetypes_files..
it creates the file cfile as a C file with strings containing all the build menu labels it finds in the listed filetypes files (filetypes.* would be good:-) this cfile can be processed by your translation tools (tested with xgettext) along with all the other program files to extract strings for translation. A good name for cfile might be buildmenutranslate.h
run as: xbuildmenu.py upd cfile podir
it searches the po files in podir for strings taken from the cfile and using the information in the structured comments in the cfile copies the translation back into the filetypes files with a language marker the same as the po file name, eg de.po gives [de] on the config file entry.
It should be easy to call this from the waf script since you are guaranteed that python is available :-). We are only talking about the standard filetypes as delivered with the system so there is no need for users to run this, just run when translations are updated in svn.
It uses grep to speed its file search by eliminating lots of files (hopefully)
Cheers Lex
2009/8/26 Lex Trotman elextr@gmail.com:
2009/8/26 Nick Treleaven nick.treleaven@btinternet.com:
Yes, but any default string could be added to the codebase for translations, not just compile and build. Assuming it's a 'general' kind of menu label, things which would be useful for several filetypes.
All the strings in the code that appear as labels should already be marked for translation, if I missed any thats a bug :-)
There isn't any way of changing the default label string to a different default depending on filetype. The intention is that if you want to change a filetype menu label it is configured in the filetypes file along with the command and overrides the default.
Let me look at a possible solution in a few days.
Cheers Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Fri, 28 Aug 2009 12:16:11 +1000, Lex wrote:
Sorry guys, don't use it as is, the Python config parser removes comments from the config file, not what we want, back to the drawing board.
Before you spend too much time on this: do we really need this? do we really want this?
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.
Regards, Enrico
2009/8/29 Enrico Tröger enrico.troeger@uvena.de:
On Fri, 28 Aug 2009 12:16:11 +1000, Lex wrote:
Sorry guys, don't use it as is, the Python config parser removes comments from the config file, not what we want, back to the drawing board.
Before you spend too much time on this: do we really need this? do we really want this?
Well you know at the moment, no no, but the feature of labels adjusted by config file is only just available, I'm guessing, but I think that its use will grow over time. Of course I could be wrong, I have been in the past :-)
So maybe we could forget it until the demand was there, but with no guarantees of time availability or interest in fixing it at that time.
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.
That looks kinda like a maintenance nightmare keeping the strings in the code in line with the labels in config files, please don't go there for your own sakes ;-)
Cheers Lex
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
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.
That looks kinda like a maintenance nightmare keeping the strings in the code in line with the labels in config files, please don't go there for your own sakes ;-)
It depends how often the labels are added/removed/changed. Will it that often?
Regards, Enrico
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 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...
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:
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
That looks kinda like a maintenance nightmare keeping the strings in the code in line with the labels in config files, please don't go there for your own sakes ;-)
It depends how often the labels are added/removed/changed. Will it that often?
As I said above, its unknown, just have to see.
Cheers Lex
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
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.
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.
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?
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
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