Re: [i18n]Source packages and translation templates q.
Quoting Neil Williams (codeh...@debian.org): (of course, I mostly disagree with the initial comment as most, if not nearly all, Debian developers are now very i18n-friendly and most of the time do what's needed to make translators' work easier) Translators don't want their work discarded, upstream don't want to waste time putting in PO files which are already out of date. Therefore, putting a POT file in the source package can be precisely the WRONG thing to do. What needs to be done is a call for translations *before* the release, giving time for all updated translations to be received and then the package released and uploaded with as many translations updated as possible. When the POT file changes, another string freeze, another call and the package gets uploaded with updated strings already in place. Well, here I feel the need to comment. This is quite theoretical assumption. If this reasoning is pushed, then nearly no localization works happens during the release cycle and everybody waits for the freeze. The, when the freeze comes, translators are squashed with gazillion of call for l10n updates. So, by far, regular updates (and therefore regular calls for l10n updates) are really needed. For instance, look at dpkg or apt translation work: only those who kept the pace can now follow the huge numnber of needed updates (I'm still fighting with dpkg manpages French translations just because I gave up on updates for a few months). So, anything helping this to happen is welcomedwhich includes providing up-to-date POT files (and keep them in the various VCS which is something I always fought for. Therefore, I think you should think this through more carefully. Blindly enforcing that all source packages which support l10n also include the POT file is counter-productive. Encouraging *some* to include POT files once the package is in a state that the strings don't change that much any more is good. Encouraging maintainers to allow time for a genuine string freeze and make a call for translations, including the updated translations in the actual release, is a FAR BETTER idea. That works well with developers that have a strict developing agenda with planned released, development plan, etc. You're one of these, Neil, and that's much appreciated. However, other development styles may better fit with constant providing of localization material. signature.asc Description: Digital signature
Re: [i18n]Source packages and translation templates q.
On Mon, 6 Sep 2010 06:49:12 +0200 Christian PERRIER bubu...@debian.org wrote: Quoting Neil Williams (codeh...@debian.org): (of course, I mostly disagree with the initial comment as most, if not nearly all, Debian developers are now very i18n-friendly and most of the time do what's needed to make translators' work easier) Translators don't want their work discarded, upstream don't want to waste time putting in PO files which are already out of date. Therefore, putting a POT file in the source package can be precisely the WRONG thing to do. What needs to be done is a call for translations *before* the release, The release referred to here is not the Debian (downstream) stable release but the upstream package-specific release which doesn't then coincide with other releases, mostly. Sorry that this wasn't clear. giving time for all updated translations to be received and then the package released and uploaded with as many translations updated as possible. When the POT file changes, another string freeze, another call and the package gets uploaded with updated strings already in place. Well, here I feel the need to comment. This is quite theoretical assumption. If this reasoning is pushed, then nearly no localization works happens during the release cycle and everybody waits for the freeze. The, when the freeze comes, translators are squashed with gazillion of call for l10n updates. Hence the need to do this by the package release schedule, not the distribution release schedule. So, by far, regular updates (and therefore regular calls for l10n updates) are really needed. Yes - each time an upstream package (because that is where the non-debconf translations necessarily live) is released, there should be a preceding update of the translations in that specific package. Alternatively, if the package strings are stable and translator work wouldn't be wasted, then the POT should be packaged and translations done after release. The problem with that is many packages which have stable translatable strings are also stable source code and don't release often - having the up to date POT file in the source package doesn't help anyone if the package itself does not get released for months after the i18n bug is filed. Very few upstreams bother with interim i18n releases in the absence of other bug fixes. I mostly want to avoid throwing away translated strings here but I also want to try and avoid having usable translations hanging around in our BTS or the upstream bug tracker for months on end because the rest of the package doesn't need a release. I have two such bugs now - the library concerned just doesn't warrant a new upload. It won't work it's way up my TODO list for quite some time yet. The two bugs concerned were filed after the original deadline for the previous string freeze and are hence waiting for the next one. It comes down to a problem with the gettext design - it's too tightly integrated into the upstream build process to be able to easily handle separating the po/ directory into a separate upstream tarball which could be updated separately from the rest of the source code. Documentation PO support can be done that way, (but mostly isn't), runtime program output translations are harder. For instance, look at dpkg or apt translation work: only those who kept the pace can now follow the huge numnber of needed updates (I'm still fighting with dpkg manpages French translations just because I gave up on updates for a few months). I believe there is an argument here for not expecting i18n updates for 1.2.x updates, only in 1.x.0 updates. Native packages do need to be handled differently but, again, churn doesn't help anyone because it is demotivating. (As you, of all people, know all too well.) Why translate strings for 1.2.5 if the functionality is modified or even removed in 1.3.0? This is a particular problem with documentation because sometimes point releases introduce complex new ideas which need docs. There's no one-size-fits-all approach possible here, teams need to coordinate their i18n work. So, anything helping this to happen is welcomedwhich includes providing up-to-date POT files (and keep them in the various VCS which is something I always fought for. Churn is the problem here, IMHO. Many packages just change too fast at specific times to allow generated files like the POT into the VCS. i.e. the source code is changing and whether or not the translatable strings actually change, committing the POT every time (because it timestamps itself every time it is checked) is a PITA. Yes, wrappers can be written etc but those are VCS or package specific. Keeping an up to date POT file in VCS is generally the wrong approach because it is a generated file and because intltool insists on timestamping the damn file every time the build so much as looks at it. Then, if PO files exist, every single one is updated every single time a new line is
Re: [i18n]Source packages and translation templates q.
I demand that Neil Williams may or may not have written...
[snip]
It comes down to a problem with the gettext design - it's too tightly
integrated into the upstream build process
Not to mention the source itself, given that the .pot is (normally) generated
by invoking a specific target in po/Makefile.
to be able to easily handle separating the po/ directory into a separate
upstream tarball which could be updated separately from the rest of the
source code.
Anybody who asks me to do that will get a negative answer, though I suppose
that an interim release containing just updated .po files is possible (but
that would rely on no strings having been changed).
[snip]
Churn is the problem here, IMHO. Many packages just change too fast at
specific times to allow generated files like the POT into the VCS. i.e.
the source code is changing and whether or not the translatable strings
actually change, committing the POT every time (because it timestamps
itself every time it is checked) is a PITA.
Agreed. There have been times when I've taken a diff and stripped out any
hunks which change only line numbers...
[snip]
Keeping an up to date POT file in VCS is generally the wrong approach
because it is a generated file and because intltool insists on timestamping
the damn file every time the build so much as looks at it.
Agreed. Look in the xine-lib repository (upstream), for example, and you'll
see some translation synchronisation commits. If the build process causes
po/*.po{,t} to be regenerated, those changes are (normally) manually
discarded before the next commit.
[snip]
--
| Darren Salt| linux at youmustbejoking | nr. Ashington, | Toon
| using Debian GNU/Linux | or ds,demon,co,uk| Northumberland | back!
| + They're after you...
You mean I can send mail to myself?
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/515806bf68%li...@youmustbejoking.demon.co.uk
Re: [i18n]Source packages and translation templates q.
On Mon, Sep 06, 2010 at 05:53:02PM +0100, Darren Salt wrote: I demand that Neil Williams may or may not have written... Churn is the problem here, IMHO. Many packages just change too fast at specific times to allow generated files like the POT into the VCS. i.e. the source code is changing and whether or not the translatable strings actually change, committing the POT every time (because it timestamps itself every time it is checked) is a PITA. Agreed. There have been times when I've taken a diff and stripped out any hunks which change only line numbers... There's a solution to this: Add --no-location to XGETTEXT_OPTIONS in po/Makevars. Now those stupid comment lines with the source file and line number are no longer generated (what use were they in the first place?)! Now your .pot and .po files will only ever change if a translatable string changes in the sources. Score! With this strategy you can keep the po/* files continually up-to-date because they now only change when they actually have genuine changes. All the genuinely pointless churn is gone. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: [i18n]Source packages and translation templates q.
I demand that Roger Leigh may or may not have written... On Mon, Sep 06, 2010 at 05:53:02PM +0100, Darren Salt wrote: I demand that Neil Williams may or may not have written... Churn is the problem here, IMHO. Many packages just change too fast at specific times to allow generated files like the POT into the VCS. i.e. the source code is changing and whether or not the translatable strings actually change, committing the POT every time (because it timestamps itself every time it is checked) is a PITA. Agreed. There have been times when I've taken a diff and stripped out any hunks which change only line numbers... There's a solution to this: Add --no-location to XGETTEXT_OPTIONS in po/Makevars. Now those stupid comment lines with the source file and line number are no longer generated (what use were they in the first place?)! Well... I'm aware that some translators have made use of this information... [snip] -- | Darren Salt| linux at youmustbejoking | nr. Ashington, | Toon | using Debian GNU/Linux | or ds,demon,co,uk| Northumberland | back! | + http://www.youmustbejoking.demon.co.uk/ http://tlasd.wordpress.com/ No man is rich enough to buy back his past. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5158146334%li...@youmustbejoking.demon.co.uk
Re: [i18n]Source packages and translation templates q.
On Mon, Sep 06, 2010 at 08:22:01PM +0100, Darren Salt wrote: I demand that Roger Leigh may or may not have written... On Mon, Sep 06, 2010 at 05:53:02PM +0100, Darren Salt wrote: I demand that Neil Williams may or may not have written... Churn is the problem here, IMHO. Many packages just change too fast at specific times to allow generated files like the POT into the VCS. i.e. the source code is changing and whether or not the translatable strings actually change, committing the POT every time (because it timestamps itself every time it is checked) is a PITA. Agreed. There have been times when I've taken a diff and stripped out any hunks which change only line numbers... There's a solution to this: Add --no-location to XGETTEXT_OPTIONS in po/Makevars. Now those stupid comment lines with the source file and line number are no longer generated (what use were they in the first place?)! Well... I'm aware that some translators have made use of this information... Couldn't they just have used grep? IMO the disadvantages of having that constantly changing information far outweigh the advantage of having it there for occasional use (and IME most of the time the translators just get the po file by mail and never look at the source). Being able to merge/cherry-pick without having hundreds of conflicts is also a major advantage. How often do people make use of the information, and what for? (I'd be genuinely interested to know; I haven't had any complaints since I turned them off, but getting concrete information about their usefulness is difficult.) Do any translators have any comments? Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: [i18n]Source packages and translation templates q.
Quoting Roger Leigh (rle...@codelibre.net): How often do people make use of the information, and what for? When it comes at me: never. I very much prefer having the previous original version comments (lines starting with #|) that help *a lot* spotting what changed in a fuzzy string (intelligent PO editors can even used a specific color display with this). The hint to produce these is using msgmerge --previous in the updatepo targets of makfiles (I'd be genuinely interested to know; I haven't had any complaints since I turned them off, but getting concrete information about their usefulness is difficult.) Do any translators have any comments? As said, I don't often have any use for them, for source code. Sometimes, when I spot a typo or error in the original string, I can more easily provide a patch, but grep would be enough for this, roughly. For debconf PO translations, these comments are useful for the podebconf-display-po tool. However, I'd like to add that I'm certainly far from knowing all neat uses of stuff in gettext...so there may be good valid use cases for such comments. I wouldn't recommend dropping them without deep thinking. signature.asc Description: Digital signature
Re: [i18n]Source packages and translation templates q.
On Mon, 6 Sep 2010 20:47:35 +0100 Roger Leigh rle...@codelibre.net wrote: Add --no-location to XGETTEXT_OPTIONS in po/Makevars. Now those stupid comment lines with the source file and line number are no longer generated (what use were they in the first place?)! Well... I'm aware that some translators have made use of this information... PO editors can use the comments to display the relevant source alongside the translation which can help translators get some idea of what something like this might mean: # foo.pl:15 #, c-format msgid=%s: checking %s for %s in %s\n msgstr= An alternative ( IMHO the better solution) is for upstream to use comments immediately above such strings to provide that context: # Translators: variables are: progname, package, file and suite. This is important because many languages do not use the same word ordering as English and many translators are not familiar with what the source code might mean by: printf(_g(%s: checking %s for %s in %s\n, $prog, $pkg, $f, $v); This only gets worse when the string needs to use ngettext for plurals support. Couldn't they just have used grep? That's about as friendly as RTSL or RTFM. IMO the disadvantages of having that constantly changing information far outweigh the advantage of having it there for occasional use (and IME most of the time the translators just get the po file by mail and never look at the source). I'm not defending this information in the common case, just that there are some uses for it, intermittently. It could do with being a lot easier to turn on and off - preferably without needing source code files like po/Makevars to be edited and therefore committed to VCS. e.g. an environment variable could be set by default to turn it off and unset when running via debian/rules to turn it back on. Being able to merge/cherry-pick without having hundreds of conflicts is also a major advantage. True - however, if a merge goes wrong, the comments can actually be useful, especially as the comments include line numbers. How often do people make use of the information, and what for? I use it upstream, but only from time to time and for specific problems - often related to merging from branches and similar. It could be regenerated when the need arises if, as above, the switch could be made without needing to edit (and commit) files. Of course, this doesn't prevent intltool timestamping the POT and therefore the PO files, it just makes it easier to tell if the only change is in the timestamp. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpHzfS6wUvSp.pgp Description: PGP signature
[i18n]Source packages and translation templates q.
Why Debian maintainers never generate pot files in source packages? It makes translation very difficult, not surprising no-one interested in translation. Is there some policy which controls that?
Re: [i18n]Source packages and translation templates q.
On Sun, 5 Sep 2010 20:27:13 +0700 davian...@gmail.com wrote: Why Debian maintainers never generate pot files in source packages? This generalisation is undeserved. There are packages that contain up to date POT files in the source package - I maintain several. However, it does need to be only some which package the POT file. It makes translation very difficult, not surprising no-one interested in translation. The POT file should not always be in the source package because that is too late. The POT file should be sent out for updates before the source package is uploaded. Is there some policy which controls that? Source packages are a form of string freeze, so it can be useful to prepare and update POT files in the build process. What is not generally useful is for packages to contain POT files, receive PO translations and then find that so much has changed in the POT for the next, unreleased, version that most of the translated strings for the current version already in the archive are thrown away. Translators don't want their work discarded, upstream don't want to waste time putting in PO files which are already out of date. Therefore, putting a POT file in the source package can be precisely the WRONG thing to do. What needs to be done is a call for translations *before* the release, giving time for all updated translations to be received and then the package released and uploaded with as many translations updated as possible. When the POT file changes, another string freeze, another call and the package gets uploaded with updated strings already in place. Therefore, I think you should think this through more carefully. Blindly enforcing that all source packages which support l10n also include the POT file is counter-productive. Encouraging *some* to include POT files once the package is in a state that the strings don't change that much any more is good. Encouraging maintainers to allow time for a genuine string freeze and make a call for translations, including the updated translations in the actual release, is a FAR BETTER idea. Don't look to source packages to contain POT files - look to encourage maintainers to seek updated PO translations *before* release / upload by sending the updated POT to the relevant mailing lists. $ podebconf-report-po --notdebconf --call -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgprmVOoPmJ7n.pgp Description: PGP signature
