GNOME Bugzilla – Bug 327507
Need better documentation for translating various file types
Last modified: 2012-03-16 12:39:35 UTC
Problem: In our application (gnucash) the schemas files are not included into the pot file by intltool-update. Cause of the problem: The regexp in intltool-update for categorizing the "schemas" files is given as "schemas(?:\\.in)+|" (intltool-update.in.in line 72). The "+" at the end means that the preceding expression, here the ".in", has to appear *one* or more times. But in many applications (including gnucash) the schemas files do not appear with trailing ".in" and only end in "blabla.schemas". Those files will not be found with this regexp and also with the regexp in line 242. From how I understand the intltool-update script, the "+" metacharacter needs to be replaced by a "*" metacharacter. A patch would look as follows: 72c72 < "schemas(?:\\.in)+|". # GConf specific --- > "schemas(?:\\.in)*|". # GConf specific 242c242 < elsif ($type =~ /schemas(\.in)+$/) --- > elsif ($type =~ /schemas(\.in)*$/)
The .in is required for the translation of schemas files to work. The way it works, is that @INTLTOOL_SCHEMAS_RULE@ transform *.schemas.in into *.schemas, by merging the translated strings back in. This is how schemas files have always worked. Is there some other way which you are expecting them to work? GConf itself, and other applications using it, do not know about the *.mo files for random applications, and do not posess the code to determine those files, and load translations from them. The translations must be in the schemas files to be of any use. So, this isn't really a code problem in intltool. Perhaps a documentation issue for both intltool and GConf though. I'll change the bug title to reflect that. However, this does not block #327353 as it seems. So, I'll add myself to the CC: list there, and help with getting the schemas translated in that bug.
Oooh, my gnucash colleagues and I didn't know about @INTLTOOL_SCHEMAS_RULE@. Instead, we only know what is written at http://www.gnome.org/projects/gconf/ where in the section "Application developer information" it says: To install schemas, your Makefile.am should have something like: schemadir = @GCONF_SCHEMA_FILE_DIR@ schema_DATA = metacity.schemas There's no mention of a "metacity.schemas.in" or the above rule here. How should this be done instead? We can discuss here directly, as I also have full gnucash SVN access, and the result of the discussion can go into the gconftool documentation...
Look at other projects: gedit/data/Makefile.am: schemasdir = $(GCONF_SCHEMA_FILE_DIR) schemas_in_files = gedit.schemas.in schemas_DATA = $(schemas_in_files:.schemas.in=.schemas) @INTLTOOL_SCHEMAS_RULE@ intltool/README already has a section which mostly applies to schemas as well: --------------------------------- cut -------------------------------- Extra Steps for SERVER Files (formerly .oafinfo or .oaf) ............................. To get server translation extraction and merging requires a few more steps: o Rename your .oafinfo (or .oaf) files to .oaf.in or .server.in and put an underscore before every value property for string attributes that should be localized. o Add the new .oaf.in or .server.in files to POTFILES.in. o Put lines like these in every Makefile.am that installs oaf files: --- start ---- oafdir = $(datadir)/oaf oaf_in_files = My_OAF_info_file.oaf.in oaf_DATA = $(oaf_in_files:.oaf.in=.oaf) @INTLTOOL_OAF_RULE@ EXTRA_DIST=$(oaf_in_files) $(oaf_DATA) --- end ---- At this point, your oaf translations will be extracted and merged. Also, so long as you are renaming the .oafinfo files to .oaf.in, you should take the opportunity to rename them to the new base naming convention, with namespacing, for example: foo.oafinfo --> GNOME_Foo.oaf.in foo-baa.oafinfo --> GNOME_Foo_baa.oaf.in --------------------------------- cut -------------------------------- Instead of .oaf and .server, you use .schemas, instead of INTLTOOL_OAF_RULE, you use INTLTOOL_SCHEMAS_RULE, etc. The same is true for XML, .desktop... We definitely want some docs rewrite to introduce all the things in a nice, clean way.
Btw, Malcolm has earlier written a nice guide: http://gnome.org/~malcolm/i18n/makefile-changes.html Do we want to include it inside intltool/help and update it there? (woops, didn't mean to close it ;)
intltool has switched from the GNOME to the launchpad.net infrastructure nearly three years ago: https://mail.gnome.org/archives/gnome-i18n/2009-April/msg00275.html The intltool product in bugzilla.gnome.org has been deprecated and closed for new bug entry since April 2009. I am now closing all remaining open reports about intltool as NOTGNOME as part of GNOME Bugzilla Housekeeping. Reporter: If the problem that you reported here is still valid in a recent version of intltool we kindly ask you to report it again to https://bugs.launchpad.net/intltool/ so the intltool developers get notified about it.