in Czech this ends up as
   "Přesunout kárová trojka na kárová dvojka."
for example.
   "Přesunout károvou troujku na károvou dvojku."
would be correct I think.

msgid "Move %s onto %s."
msgstr "Přesunout %s na %s."

msgid "the three of diamonds" (Nominative and Accusative case)
msgstr "kárová trojka" (Nominative case)

msgid "the two of diamonds" (Nominative and Accusative case)
msgstr "kárová dvojka" (Nominative case)

Please fix this soon, even if it does create more strings - at least it's not untranslatable anymore.

(See also bug 50676, bug 113366.)

I'm sorry, but this requires extensive changes to the scheme code, and is out of scope for 2.24.

Sure. It's totally fine if we fix it early for 2.25.

chpe: Plans to work on this somewhere in the next weeks?

I currently don't plan to work on this for 2.26, no. Sorry.

retarget as per last comment

I'd like to work on this, but I'm not clear on what we should be doing.

2916 strings consisting of "Move X onto Y." is not an option I'm willing to implement.

Would it be OK with everyone if we made it a policy to only split sentences of the form "Move X onto Y.", where X and Y are both names of cards, and split those into "X" and "Move %s onto Y."?

That means we would split "Move the two of diamonds onto the three of diamonds." into "the two of diamonds" and "Move %s onto the three of diamonds. However, we would not split "Move the ace of diamonds onto an empty foundation slot."

To enforce this, we would deprecate the (get-name) function in favor of calls like (hint-move-to-foundation source-slot num-cards dest-slot). That's more information than is necessary to form the string (and simpler calls would likely be needed in some cases), but it's also potentially useful for bug 365585.

See 

http://mail.gnome.org/archives/gnome-i18n/2003-May/msg00170.html

for the discussion leading to the current "solution".

In short: we knew it was a disaster when we implemented it, but having thousands of extra strings was deemed worse.

A visual indicator has always struck me as the cleanest solution to this problem (not that I ever got around to implementing it when I was maintaining aisleriot).

What about having each %s string twice and marked with context, like "this is the name of the card X as in the sentence "Move X onto Y""" and "this is the name of the card Y as in the sentence "Move X onto Y""? Not perfect but probably much better, plus only 54 additional strings (if i get it right).

Just also have to make sure that there's no nominative usage of X or Y, or mark that with another context (another 54 strings).

I may sound a bit too global, but the good solution of the problem would be to introduce grammatical cases to gettext. In this very case it would be enough (without any patches to gettext :) to produce an Accusative form for each card value (amounting to 9 strings) and a Genitive form for each card suit (amounting to other 4 strings). The problem of combinatorial explosion of strings is then solved in a natural way, although the code that generates the string "Move X-value X-suit onto Y-value Y-suit" becomes a bit more complicated.

Not a blocker (won't get done for 2.28).

Mass-moving only open aisleriot bugs to the new product. Search for "aisleriot-mass-move" to filter them.

Any plans to fix this in any near future? What we have now is not localizable for my language. Please at least use context solution. Please pay attention to i18n since it's one of GNOME claimed priorities.

No, no one is working on this.

I'm happy to implement whatever logic we need in the scheme code and purge (get-name), but someone who understands the problem and understands gettext needs to do the heavy lifting. Right now, all we have in scheme is a function that takes an English string and spits out a localized string. To change the translation based on grammatical cases, we'd need a different kind of translation function in our code and the ability to scan for it when generating .po files. But I don't know how to do that or what features translators need.

And no one commented on my suggestion of splitting "Move %s onto %s" strings into "%s" (which would have to be used only for direct objects, I guess) and "Move %s onto a specific card that is named here." It's a bit of hassle for translators, but I could implement that without help, if it's actually good enough. I have no way of knowing if it is.

I find your solution ok for translators. I'm not sure if any languages in the world would have problems with this, but at least these messages would be translatable in most European and Slavic languages.

Is it possible to implement it for 3.4 release?

Should be possible, but it's a matter of putting in a new system and then modifying every existing game. So it may be that you have the tools to do the translation correctly but some games do it the old wrong way in 3.4.

Are strings like "Move %s onto an empty foundation slot." OK? I'd rather not have 54 strings for each type of non-card you can move something to, as I'm guessing there are around 10 of them. (If we use a card name anywhere else in a sentence, I figure we WILL need 54 strings for it, but I'm hoping that case is more rare.)

If you are to use 'Move %s onto an empty foundation slot.' message then you should create special gettext context for each card name which substitutes %s. Basically, use should add the whole message where this card name occurs, in msgctxt. So for each message where you use this kind of substitution, you will need to have +54 messages. It's cumbersome, but it works for translators.

I'm not familiar with msgctxt. It sounds like it would require wrapping a new localization function for use in the scheme code and doing whatever needs to be done to make sure we can find those strings in the scheme code. That requires someone with a better understanding of the tools than I have. What I can do is avoid splitting those sentences, so you end up with 54 strings that are a full sentence.

Actually, though it sounds scary, there is nothing wrong with un-splitted sentences. On the opposite, this is the recommended way to do it. Of course, it will raise the number of messages to translate dramatically (52x52?..), but:

1. it will be the best solution for every language on the planet.
2. translators are better to use gettext editors with support for translation memory and suggestions. If done so, no big problems to update translations with un-splitted messages then.

But since this is a major change, I would suggest to raise the question among gnome-i18n@ and maybe some interested developers.

I need someone to tell me whether the master branch is frozen, because apparently I'm not smart enough to understand https://live.gnome.org/Schedule.

It was branched for release (gnome-3-2) and hence it's not frozen anymore (gnome-3-2 is frozen from now on).

Yes, master is open for all commits; only gnome-3-2 branch is (string, UI, feature) frozen.

I guess it would be better to expose a new C function to the scheme code, that takes the cards as input and returns the corresponding string. That way we don't have to deal with msgctxt translations in scheme.

(In reply to comment #18)
> I'm not familiar with msgctxt.

https://live.gnome.org/TranslationProject/DevGuidelines/Translation%20contexts and https://live.gnome.org/TranslationProject/DevGuidelines/Use%20comments hopefully explains a few things.

So, I did this once before but then backed it out because I was confused and thought we were in code freeze. Anyway, I have added a new set of hint functions (well, mostly ONE hint function, hint-move) for developers to use in aisleriot games so that "drag and drop" hints can be translated properly. This is not using msgctxt only because I personally do not have the skills to do that. That may change shortly if Christian decides to step in, so you may want to wait a bit before translating the new strings.

Christian, please feel free to tamper with the inner workings and the return value of hint-move. If you want it to return a different type of hint, or call into some new C entry point, go ahead. Also, feel free to delete hint-get-dest-format. I promise not to rely on the way hint-move currently works or treat the result as anything other than a token to be returned from get-hint. I made hint-move take a set of piles and a location in the source pile so that, once games are using this function, we don't have to modify them AGAIN if/when we want hints to use animations or arrows or something. It uses the slot tag to determine the type of empty slots. The hint-click function is a similar concept, but I'm probably not going to convert things over to it.

The commit id for this change is f9c67a2fcc2372f008538df5cd7e85b6345464c8.

http://mail.gnome.org/archives/gnome-i18n/2011-September/msg00385.html explains how to add comments in Scheme. The entire thread was actually about this bug report.

I've removed every use of (get-name) from every aisleriot game and made the function private in ab0b57d5a92900a760384d8a0d8dbd676e725763. I believe this should make it possible to translate all the hint strings correctly, and if any problems remain we should be able to fix them in (get-hint).

There were some uses of get-name that weren't for "Move x onto y." type strings, and those have been replaced with full strings that include the card names.

The strings for individual card names are still present, but they will only be used in sentences like "Move ~a onto the ace of clubs.", "Move ~a onto the foundation." or "Move ~a onto an empty foundation slot."

It'd be nice to add a comment to that effect to the individual card name strings. Is there an easy way to apply it to all of them?

Unfortunately only way the intltool extractor is going to pick up comments if it's duplicated before each string.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/aisleriot/-/issues/102.