Am Samstag, 21. Juli 2007 23:28 schrieb Junio C Hamano: > > Agreed. I propose to throw away the "add glossary" patch and I'll > > resubmit, this time in a separate po/glossary/ directory, where each > > language will get a po file for the glossary. > > Actually, I would even suggest that we should NOT have a > separate glossary file at all, if gettext suite allows what I > outline below. > > How about having it as a part of header comment in each of the > xx.po file? I don't think this would work well. In particular, you don't get all the nice gettext *merging* features that you only get with a full-blown po file. > The division of labor I think would make sense for message l10n > process goes like this: > > - The software developer (primarily Shawn): responsible for > marking messages subject to i18n; Yes, except those developers who don't happen to be translators as well tend to forget the markups. I don't blame anyone for doing so - just keep in mind that translators have to give feedback about missing markups, and they hopefully will do so. > - The i18n coordinator (could be Shawn but anybody else can > volunteer; as things stand, I think Christian and Johannes > are doing this): responsible for running "make > po/git-gui.pot; make update-po" from time to time in order to > keep po/*.po in sync with the vocabulary. Actually, please DO NOT RUN update-po except right before a new tarball is being packaged and distributed! It sucks royally if I have updated my de.po translation, only to discover someone has run update-po on the server and I have to figure out how to get out of the de.po conflicts. There will be conflicts after each and every update-po because the line numbers in the po file will have changed inevitably -- but the actualy content in terms of messages might be completely unchanged. For that reason, please use the update-po rule AS SELDOM AS POSSIBLE. Thanks a lot. > initially, populate "glossary" part in po/git-gui.pot; > > as needed, add entries "glossary" part in po/git-gui.pot, and > (if possible) add corresponding placeholders to po/*.po; Again, this doesn't work well, and depending on the po file editor that is used by a translator they might not see this comment block anyway. I would instead propose a subdirectory po/glossary; a CSV file that contains the terms itself; a csv-to-po converter script that will turn the terms into a git-gui-glossary.pot; and a po file for each language. > - Translators (one for each language): responsible for updating > po/xx.po file; > > initially, start by copying po/git-gui.pot to create > po/xx.po; > > maintainance of "glossary" part of po/xx.po could also be > made this person's responsibility instead of i18n > coordinator's. > > This way, the translators do not have to be so familiar with the > gettext toolchain nor even have to have gettext installed. Translators who are unfamiliar with gettext are a mixed blessing. Anyone is able to contribute a bunch of initial string translations, especially if there hasn't been a translation before. But if someone or a team wants to achieve a really *high-quality*, 100%, consistent, and understandable translation, the translators must be able to test the translation a lot, which implies they must be able to generate the .msg files, which requires the gettext toolchain anyway. For that reason I wouldn't spent too much effort to enable translation work without gettext tools; instead, I'd rather encourage to optimize the setup for those translators that have the full toolchain available. Christian - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
