Some more detail, since I suppose I am not the only one who needs to read these bugs:

The %s in the example above is going to be a color, Red or Green or Blue, or for high-contrast themes the name of a shape. These are defined in theme.c.  Appending to that string works fine in many languages, but it could be impossible to translate into other languages. Instead, we need to write out the strings in full, e.g. "Red’s Turn" and "Red Wins!"  The easiest way to do this would probably be to expand the struct in theme.h with fields for each of the needed strings, written out in full.  This might seem a bit messy, but stuff like this is not uncommon when dealing with translatable strings.

Also, note that modern GNOME programs use the curly apostrophe ’ rather than the ' key on your keyboard.

So, briefly, there are two stages to translating open source programs: internationalization (i18n) and localization (l10n).  l10n is the process of translating, and a l10n bugs would be problems with individual translations. As a developer, I don't really care about those (in the sense that they're not my problem -- I can't fix a bad translation if I don't know that language). In contrast, i18n is the process of preparing text for l10n, and that is the developer's responsibility.

To make a string translatable, we use GNU gettext [1]. If you pass a string to the gettext() function, it becomes translatable. GNOME programs use a macro _ which expands to gettext to make this less annoying. (In Vala, it's a function, since Vala has no macros.) For example:

string s1 = "I am untranslatable. I'm not displayed to the user.";
string s2 = _("I am translatable, display me please!");

So marking strings for translation is clearly pretty simple. But there are a few gotchas. For example, if you add two strings together, you have to be super careful, since you could make the string impossible to translate correctly, as in the first post in this report:

str = g_strdup_printf (_("%s’s Turn"), who);

That works great for English, but in other languages, the string 'who' may need to be translated differently depending on context, and it might not necessarily belong at the start of the string, either. Instead, we have to mark the entirety of the string for translation, so we need separate _("Red’s Turn") _("Green’s Turn") _("Red Wins!") etc.

[1] https://www.gnu.org/software/gettext/

Created attachment 272578 [details] [review]
Patch for the bug

Hi,

Kindly find my proposed patch for this bug attached. Do let me know if it's what you are looking for.

Thanks.

Review of attachment 272578 [details] [review]:

That looks like it will work.

I think it would be better to expand the existing struct with two more fields, rather than adding two news structs. Notice that those structs are mostly redundant with the existing one, and you only need the last field of each.

Created attachment 272618 [details] [review]
Improved Patch

Hi,

I have now expanded the original struct instead of using two additional ones.
Let me know if this is fine.

Review of attachment 272618 [details] [review]:

Much better, thanks!

Hi, I just wanted to note that this line will in no way translate the content of 'who':

g_strdup_printf (_("%s"), who);

gettext will translate "%s", which is unnecessary, then replace the untranslated 'who' variable into it. gettext must be called on the who variable, not on the "%s".

As the modification will simply remove translatable strings, not modify or add strings, this can be changed without requiring string freeze exception.

Right, but we did call gettext on the line above, so there's no functional change here -- just a code cleanup, right?

Double-check me on this please. :)  Thanks for reopening!

The following fix has been pushed:
03a4e8c Clean up translation of player "name"

Created attachment 285031 [details] [review]
Clean up translation of player "name"

Thanks, looks fine now.