Every change has a reason. https://projects.archlinux.org/pacman.git/commit/?id=8725dce2948f9e1eb9c6f9d66cdb5ef985e6de6c

commit 8725dce2948f9e1eb9c6f9d66cdb5ef985e6de6c
Author: Chantry Xavier <shiningxc@gmail.com>
Date: Mon Mar 3 21:32:54 2008 +0100

Disable the line number in .po files.

Add the --no-location xgettext option to disable the line numbers. They are
not very useful, and generate a huge number of pointless line changes on
every update.

Ref: http://www.archlinux.org/pipermail/pacman-dev/2008-March/011332.html

Signed-off-by: Chantry Xavier <shiningxc@gmail.com>

Thanks for the information, but allow me to disagree about the usefulness of this feature for the following reasons:

- While it introduces a lot of "pointless line changes", it makes very easy for the translator to figure out which line is in which file, so one can read around this line to see the context.
- Without the src code references in strings, I have to run several 'grep -R <string-content>', or whatever cmd line, if I want to understand the meaning of a string (and sometimes it get cloudy) or if I want to be highly accurate in the translation (and I want to be accurate - I'm perfectionist on pacman and AUR translation ;)
- With a translation tool (ex.: poEdit), one can open the source code in view-mode through the GUI (how to reproduce: do the "Steps to reproduce above", run poEdit in a PO file, right-click to see the reference)

Let me show one example that I consider critical:

msgid "Creating working copy of %s %s repo..."

In the above msgid I would never figure out that first %s is repo name and the second is 'bzr' without looking at the src code. It makes different for pt_BR laguange because I need to invert order of the variables, using %1s and %2s, to maintain its meaning.

msgstr "Criando cópia de trabalho do repositório %2s de %1s..."

(Aside)
msgstr "Criando cópia de trabalho do repositório %2s de %1s..."
Please don't - that is in the pacman-scripts file so order parameters can not be used.

That leads me to believe this separation of translatable and non-translatable parts isn't going to work so well; assuming every language orders things in the same way is bound to be wrong in several cases.

Things like '--option option description' are obvious candidates for splitting; the above bit seems like a thing we can't safely split in a translatable way. I do agree that having to proofread translations to look for those bits that shouldn't be translated would really suck though. Of course, these things should get caught and corrected quickly if people are actually using the translations.

I didn't know there was such case that inverting order of parameters was not allowed in gettext. Thanks for letting me know. I'll proofread my translation as soon as I'm able to build AUR/pacman-git (fails in

Just FYI, you might be able to send some info for the translators using comment blocks right above the translation string plus a "XGETTEXT_OPTIONS= --add-comments" (msgctxt). e.g.: "first %s is the repo name and the second %s is 'bzr' - don't invert order here". With this, hopefully we can avoid the probability of the end-user being the proofreader.

Just to clarify - You can only not use ordering in the pacman scripts section. The pacman and libalpm sections are fine to use that.

I am also not sure that the comments work in bash scripts either - but definitely something to consider with the C code parts.

Tested in pacman-scripts from pacman-4.1.0rc1.tar.gz, and it works. It seems to be activated already but the comment requires a 'TRANSLATORS:' to be considered a 'msgctxt'. It looks usefule, mainly pointing out what is the %s variable in a string.

Anyway, with or without msgctxt, with location makes it easier (for the translator) to know where a string is from. It doesn't even bring a great increase in the file size, just a lot more lines in the commit log. IMHO, the benefit (for the translators) compensates adding the locations/references back.

+1 for removing --no-location because it's the only context besides the order of messages before there are other comments for translators. Even when there are, location will still be useful for those translators that browse the source code. If there were an option to keep the list of file names, but remove the line numbers, I wouldn't miss the line numbers.

About positional parameters: would be great to have the inability to use them in pacman scripts documented at https://www.archlinux.org/pacman/translation-help.html

Code comments starting with "TRANSLATORS:" are not msgctxt (also known more generally as disambiguation context). They are instead extracted comments. A random example from random another project using gettext (trader):

#. TRANSLATORS: "Player" is used as a column title in a
#. table containing all player names.
#: src/game.c:606 src/move.c:868
#, c-format
msgctxt "subtitle"
msgid "Player"
msgstr "Pelaaja"

Both generally work for adding comments for translators. Adding disambiguation context also solves another problem, though. Because the disambiguation context is part of the message key, adding or changing it makes the translations fuzzy, which forces all translators to review them. This is useful because some translations probably had mistakes because of missing context.

A question for translators here. My understanding is that this option provides details of which line the string came from in the source. As you still need a copy of the source to locate the context, does this have any great advantage over using a grep? Particularly given the string freeze might be followed by non-string fixes that move the strings around anyway.

A good description can bi enough for not need look the source (I say for experience), and anyway the real only form to look if a translation is ok is test "in situ" but that need maintain in sincronization translations and sourcecode for test