Re: automake po / pot file integration: when to merge the PO files?
At Tue, 7 Sep 2010 22:50:32 +0200, Ralf Wildenhues wrote: > * Yavor Doganov wrote on Tue, Sep 07, 2010 at 10:17:07AM CEST: > > В Mon, 06 Sep 2010 11:32:54 +0100, Roger Leigh написа: > > > I'm already doing this in some of my projects by adding > > > "--no-location" to XGETTEXT_OPTIONS in po/Makevars. It's a > > > massive improvement. > > > > It's a massive disaster for translators. > > > > > A question I have is "what purpose does having the line number > > > and source file serve"? > > > > Automatically jumping to the source. That's invaluable. > > Well, automatically jumping to a specific place in source code can > be achieved with a more stable indexing method that file:line: > annotations. An example is how tags/TAGS files work: they encode a > file name and a search regex that looks like a sed /^pattern/. That's a nice idea, yes. I don't know if it's easy to implement, and I'm not sure why gettext's way is the way it is, given that *tags predates it (IIRC, not sure). > Now, I'm not sure reusing tags functionality exactly is possible; > translator tools will need some adjustment to work with this. PO editors definitely would have to be modified if this approach is implemented in gettext proper, but I don't think that's a major problem to be concerned about. (They already track and adapt to changes in gettext, naturally.) The solution for Roger's problem (preventing .po/.pot VCS noise) is very simple: just don't keep the .pot in the VCS; generate it at `make dist' time. If you keep .po files in VCS (not compulsory either; some projects do not do this, but fetch the .po's at dist time), then commit only those changes that are genuine translators' modifications. Any diligent translator knows how to generate a .pot, and how to refresh the .po from it.
Re: automake po / pot file integration: when to merge the PO files?
Hello, * Yavor Doganov wrote on Tue, Sep 07, 2010 at 10:17:07AM CEST: > В Mon, 06 Sep 2010 11:32:54 +0100, Roger Leigh написа: > > > I'd like to suggest that the best way to tackle the problem is to > > simply stop generating the source file/line number comments by > > default; I'm already doing this in some of my projects by adding > > "--no-location" to XGETTEXT_OPTIONS in po/Makevars. It's a massive > > improvement. > > Improvement for you as a maintaner, probably. It's a massive disaster > for translators. > > > A question I have is "what purpose does having the line number and > > source file serve"? > > Automatically jumping to the source. That's invaluable. Well, automatically jumping to a specific place in source code can be achieved with a more stable indexing method that file:line: annotations. An example is how tags/TAGS files work: they encode a file name and a search regex that looks like a sed /^pattern/. Now, I'm not sure reusing tags functionality exactly is possible; translator tools will need some adjustment to work with this. But that adjustment would be fairly straightforward, and the resulting translation file contents could have much more stable contents. Thoughts? Thanks, Ralf
Re: automake po / pot file integration: when to merge the PO files?
В Mon, 06 Sep 2010 11:32:54 +0100, Roger Leigh написа: > I'd like to suggest that the best way to tackle the problem is to > simply stop generating the source file/line number comments by > default; I'm already doing this in some of my projects by adding > "--no-location" to XGETTEXT_OPTIONS in po/Makevars. It's a massive > improvement. Improvement for you as a maintaner, probably. It's a massive disaster for translators. > A question I have is "what purpose does having the line number and > source file serve"? Automatically jumping to the source. That's invaluable. The only case where locations do not work (and do not make sense) is for XML gibberish like .glade/.ui files. The filename is still useful, though -- I'm using it to open the file with Glade, and click around to find the message I'm interested in. > And if the original source file(s) for a string need to be found, > grep(1) is pretty fast. Try this with a non-trivial (or even trivial) package, you'd be annoyed pretty quickly. > At least for me, the translators get mailed the po file, and never > look at the source, so it's not of *any practical benefit* to anyone Yes, unfortunately these days many translators take the "black box" approach -- not only they never look at the source (which leads to amusing translations with horrible quality), they don't even compile and run the program. That's not a valid reason to cripple the .po files, though, making the life significantly harder for those who take care to test their translations properly. Source code availability *is* a prerequisite for a decent translation, and the locations of the messages are a major convenience (with a capable PO editor, of course).
Re: automake po / pot file integration: when to merge the PO files?
On Mon, Sep 06, 2010 at 11:25:44AM +0200, Bruno Haible wrote: > Hi, > > One issue still needs discussion within the planned po / pot file > integration [1]: > When should the PO files that are distributed be merged with the POT file? Just a few comments from a long-time gettext+automake user which I hope might be useful: The number one problem for me (as you identified) is the huge churn in po file content as you make source changes. I'd like to suggest that the best way to tackle the problem is to simply stop generating the source file/line number comments by default; I'm already doing this in some of my projects by adding "--no-location" to XGETTEXT_OPTIONS in po/Makevars. It's a massive improvement. Making this small change has a huge impact. po file changes are now sensible: they match source string changes only, not massive line renumbering because I added/removed some unrelated code. This makes merging between branches sensible because I don't have an entire po file full of line number conflicts I can't hope to merge manually. A question I have is "what purpose does having the line number and source file serve"? Do those benefits outweigh the massive disadvantages? And if the original source file(s) for a string need to be found, grep(1) is pretty fast. At least for me, the translators get mailed the po file, and never look at the source, so it's not of *any practical benefit* to anyone AFAICS; I've certainly had no complaints since I turned them off. With this change made, I would be fully in favour of having "update-po" run by default so that the po files are always kept up-to-date. In this situation, it makes sense--the po file changes are *entirely related* to the source changes, and can be committed together. Updating the po files by default also makes releases easier: if I tag a release and then "make dist" and find all the po files were updated, modifying the repository, I need to detag, commit the changes and retag. Updating by default means the repository is always in a "releasable state" whereby any revision can be tagged without doing additional sanity checks. 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
