Currently building PO files is broken. 'intltool-update -r' and similar commands produces lots of errors. It prevents Transifex and translators from updating translations.
What errors are you referring to? How are you building po files?
Created attachment 360812 [details] Errors I use simple 'intltool-update -r' (standard command for intltool-based projects) on current git HEAD, but Transifex also has a problem with generating POT file [1] (there should be 'Source file: po/anaconda.pot' line, as on [2]). [1] https://translate.fedoraproject.org/projects/anaconda/master/ [2] https://translate.fedoraproject.org/projects/anaconda/f11-branch/
We're using autoconf and automake to control the build process now. We're using the gettext autoconf templates modified for our po directory to control updating po files, generating gmo files, and generating anaconda.pot. So to get anaconda.pot, you need to do the following with a checked out tree: $ ./autogen.sh $ ./configure $ make -C po Depending on what release you have on your system, the configure script may or may not fail. Paste any errors you get here and I'll get those fixed up.
So if you are using non-standard make-based procedure, anaconda.pot file shouldn't be manually generated and present in repository? Without anaconda.pot, translation tools assume that project uses intltool to automatically generate one.
We're using templates provided by GNU gettext. See here: http://www.gnu.org/software/gettext/manual/gettext.html#Maintainers This method for managing translation files is in use by many projects, so there's nothing new that we've come up with. The anaconda.pot file is a built file, so we should not be storing that in revision control. Our project is not entirely based around using intltool to extract translatable strings. The majority of our strings are picked up directly by GNU gettext using their Makefile templates. For our glade files, shell scripts, and other non-standard files, we use intltool to extract the strings. We can't use one or the other, we have to use both. This is what we were doing in the past, but it was dependent on us running those commands periodically to update the anaconda.pot file in revision control. With the new system, the anaconda.pot file and translation databases are generated for each build so they are current. For anaconda, you cannot just use intltool-update -r, you will have to use the steps I described in comment #3: $ ./autogen.sh $ ./configure $ make -C po If you do not run this directly, but it's run by the translation system, then something needs to change there. We've moved away from storing data in revision control that should be generated during each build, and that includes anaconda.pot.
> We can't use one > or the other, we have to use both. This is what we were doing in the past, but > it was dependent on us running those commands periodically to update the > anaconda.pot file in revision control. With the new system, the anaconda.pot > file and translation databases are generated for each build so they are > current. Uhmm.. Good to know. This means that Anaconda can not be set as an intltool project in Transifex. I just changed it to avoid creating uncompleted POT files for . > We've moved away from storing data in revision control that should be > generated during each build, and that includes anaconda.pot. Well, with all respect, in this case I wonder if it is really a good approach. How do you think translator should get a source file to translate it? Should a translator do a checkout of anaconda and run those commands? As Anaconda is not a pure intltool-based project, which means POT can't be generated using a standard procedure, I would really encourage the Anaconda team to store the POT in VCS again and update it whenever is necessary. Transifex itself can't handle it, because it's not using a standard. BTW, what's the problem of storing the POT?
I do not fully understand how Transifex works or how the translators generally do their work. My assumption has always been they do checkout the source from git and do their work that way. The main reason I eliminated anaconda.pot from revision control is to avoid us having to periodically regenerate it. If it could be automatically generated, then we could avoid worrying about it. But it looks like that won't work for Transifex. I'll bring back anaconda.pot for now, but would like for Transifex to have the ability to build the po/ subdirectory if necessary.
Thanks, David, for deciding bringing the POT back again for now. So I have two news for you, one good and the other bad. Good: Transifex does have support for generating the POT files for projects based on the intltool i18n standard. Bad: Anaconda has an hybrid i18n support that uses not only the intltool standard of extraction of strings. So, if you really want to avoid the generating the POT file periodically, I would suggest you to make Anaconda use only the intltool standard of i18n. This way Transifex would take care of your POT generation, include sending a notification for the maintainers whenever it goes wrong, due a misconfiguration, for example. FWIW with Transifex, translators no longer need to do checkouts of code. It provides a full interface to donwload, watch, lock, edit and submit PO files back to the upstream repo. Everything using a single interface web. https://translate.fedoraproject.org/projects/anaconda/master/ Once you commit the POT back upstream, it will appear in the Anaconda page on Transifex for translators to be able to download it. (It might take a few hours until the next sync) BTW I would really like you to do it ASAP. The translation period ends on 22/09 and translators will need some time to translate the most important component for Fedora. If we don't do it know, translations will only be included for the next Fedora release (F13). Thanks for your cooperation.
Fixed in anaconda-12.26-1.