TRANSLATORS: Crowdin multi-placeholder translations poll

[ferdnyc]

Speaking of Crowdin, one for the active/experienced translators, primarily:

The situation

GSConnect contains some translatable strings where multiple variable substitutions are performed, sometimes with identical types. A perfect example is this one:

gnome-shell-extension-gsconnect/src/service/plugins/share.js

Lines 157 to 161 in 9675498

	// TRANSLATORS: eg. Receiving 'book.pdf' from Google Pixel
	body: _('Receiving “%s” from %s').format(
	packet.body.filename,
	this.device.name
	),

Technically, that string is ambiguous: There are two %s replacements, but what order are they used in? It's convention in English to apply them from left-to-right, but in some other scripts they may need to appear in the opposite order for a proper translation.

The Chinese Simplified translation of that string, for example, correctly has the translated version as:

gnome-shell-extension-gsconnect/po/zh_CN.po

Lines 990 to 994 in 9675498

	#. TRANSLATORS: eg. Receiving 'book.pdf' from Google Pixel
	#: src/service/plugins/share.js:158
	#, javascript-format
	msgid "Receiving “%s” from %s"
	msgstr "正在从 %2$s 接收 “%1$s”"

Using %n$t, where n is the index of the corresponding argument to the formatting function (counting upwards from 1 as the first/left-most argument) and t is a type character (like s for a string or d for a signed decimal value) is apparently how one performs indexed substitutions in this particular strain of string-replacement grammar.

(The digression...)

That's a new one on me, TBH. I'm pretty familiar with Python's various forms:

# Old-school dictionary-key placeholders:
>>> "%(x)s %(y)s %(z)s" % {"x": "a", "y": "b", "z": "c"}
'a b c'

# New-style indexed:
>>> "{0} {1} {2}".format("x", "y", "z")
'x y z'

# New-style tagged:
>>> "{x} {y} {z}".format(x="a", y="b", z="c")
'a b c'

# And string.Template, which is what the core
# devs actually RECOMMEND for i18n, and which
# **NOBODY** actually seems to use:
>>> t = string.Template("$red $blue $green")
>>> t.safe_substitute(dict(red="x", blue="y", green="z"))
'x y z'

...But I know there are plenty of other styles out there as well. (Wouldn't have put my life savings on %n$t to somehow hang on through that race, but hey. Life... er, uh... finds a way!)

The concern

...Aaaanyway, the point is that in each of those Python formats — as well as in the %n$s form used in the Chinese Simplified translation above, and many other similar formats — each placeholder is uniquely and unambiguously identified and associated with one and only one possible replacement string. That means that the placeholders can safely be rearranged, duplicated, omitted, etc. without causing any uncertainty about what the final, substituted string will contain. They're all substitution-safe, very much UN-like a string with two identical %s markers just thrown around willy-nilly.

And the mere fact that it's possible to use %1$s and %2$s placeholders in a substitution originally written as 'Receiving “%s” from %s' doesn't make the original string any less ambiguous. Heck, it doesn't even make the tagged substitution less ambiguous, because it's still relying on the implicit mapping between the placeholders and the arguments in the original string.

I think relying on that implicit mapping is a mistake. IMHO, if a substitution contains multiple identical placeholders, the original string should be using the %1$s/%2$s form of the placeholders, and every translation should follow suit in explicitly identifying which of the replacement strings go where.

Yes, 90% of the translations will have a structure nearly identical to 'Receiving "%1$s" from %2$s', just with different words... but there's really no down side to that! It just means the translations are safer and more precise, in all instances.

The proposal

So, I'm proposing that we update all of the ambiguous translation source strings to use indexed placeholders.

Again, this is ONLY when a string contains multiple placeholders of the same type. Which is very, very few. Looking at the current .pot file, it would be only these strings:

msgid "Failed to send “%s” to %s"
msgid "Receiving “%s” from %s"
msgid "Received “%s” from %s"
msgid "Failed to receive “%s” from %s"
msgid "Sending “%s” to %s"
msgid "Sent “%s” to %s"
msgid "%d%% (%d∶%02d Until Full)"
msgid "%d%% (%d∶%02d Remaining)"

Those would become:

msgid "Failed to send “%1$s” to %2$s"
msgid "Receiving “%1$s” from %2$s"
msgid "Received “%1$s” from %2$s"
msgid "Failed to receive “%1$s” from %2$s"
msgid "Sending “%1$s” to %2$s"
msgid "Sent “%1$s” to %2$s"
msgid "%1$d%% (%2$d∶%3$02d Until Full)"
msgid "%1$d%% (%2$d∶%3$02d Remaining)"

And all of the translations would be expected to use %n$t (where n is a digit and t is a type character) for each placeholder, instead of just the usual %s / %d. That way, everyone knows exactly what substitution they placed where, for each and every placeholder in the string.

[ferdnyc]

(OK, full disclosure. It's not NOT a motivating factor for this, that right now Crowdin's QA engine is flagging the Chinese Simplified translation of that string as having formatting issues, because the placeholders don't match the original source string.

Which just sort of... irks me. Because, that translation is formatted better than all of the other strings (including the original), and Crowdin is deducting points from them for it!

But since switching back to the un-tagged placeholders isn't an option for them, due to the reordering of the substitutions, the only course of action left is to switch everyone else to match the format of their strings.)