Untranslatable strings in the gLabels manual
Hi all, there are some strings in the gLabels manual which shouldn't be translated. These strings refer to property values which are used in the template files. If a template file contains such values, it cannot be parsed by libglabels, and the appropriate label or card will not appear in the template chooser. To remove them from the *.pot file (and the *.po files, too), I tried to mark them as follows, as suggested by Shaun McCance: untranslatable value Unfortunately, our xml2po can't handle this yet. This tool from the gnome-doc-utils package will be likely replaced by itstool [1] in the nearest future. This is a new parser which is developed close to the ITS recommendations [2]. Then I tried to omit the "its" to get it parseable with the current tools, but it doesn't work yet. For the time being, if you encounter a string in this manual which is enclosed in a tag, you dont't have to translate it. Some of these tags appear also inside other strings: #: C/mancreate.page:163(title) msgid "Template Node" msgstr "Template-Knoten" Please leave the content embedded in these tags also untranslated. Thank you for all your work, and a Merry Christmas! Mario [1] http://gitorious.org/itstool/pages/Home [2] http://www.w3.org/TR/its/ ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: gsettings-desktop schemas
Am Mittwoch, den 22.12.2010, 17:40 +0200 schrieb Lucian Adrian Grijincu: > 2010/12/20 Mario Blättermann : > > The question is now: does it make sense to make > > the keys translatable? > > > If the answer is yes (for whatever reasons) it would be extremely nice > to have them in a separate .po file. > > In my view the priority is: UI, help, gsettings, but because UI and > gsettings are mixed together and because humans have an urge to > "finish the job", gsettings strings get translated to make the whole > file 100% complete. > Doesn't matter. The "urge" to deliver 100% is no burden for me ;) But I agree with you. Some teams like to skip the schema strings for now anyway. That's why the handful of GSettings based module maintainers could think about to split the po files as GTK already does for a long time. In GTK, there are the folders "po" and "po-properties". The second one is for property nicks which likely appear in the terminal only. We could do it similarly. We create a folder "po-gsettings" and fill the file POTFILES.in with the names of the gsettings-related files. Just introduce it to the autotools stack, and we can go ahead. One hand, we have satisfied translators, other hand, the other translators which actually want to translate it may skip it until dconf-editor really works. But this procedure works only if we have the gsettings keys always in separate source files, apart from other code. Cheers, Mario ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: gsettings-desktop schemas
Hi! > But I agree with you. Some teams like to skip the schema strings for now > anyway. That's why the handful of GSettings based module maintainers > could think about to split the po files as GTK already does for a long > time. In GTK, there are the folders "po" and "po-properties". The second > one is for property nicks which likely appear in the terminal only. We > could do it similarly. No, those never appear in the terminal, those appear in glade (and other GUI design/development applications). > We create a folder "po-gsettings" and fill the > file POTFILES.in with the names of the gsettings-related files. Just > introduce it to the autotools stack, and we can go ahead. One hand, we > have satisfied translators, other hand, the other translators which > actually want to translate it may skip it until dconf-editor really > works. But this procedure works only if we have the gsettings keys > always in separate source files, apart from other code. I think they are always in different source files because they actually exist only in the gsettings-schema files. Anyway, I am not really looking forward to the automake magic that will be necessary but if someone wants to make an example module I might reconsider this. Regards, Johannes ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
