Policy request: If a string changes its meaning, use a new string ID

[Wuzzy2]

I suggest a new policy for when an existing string in the game is changed.

For example, when STR_1234 was "I need to go to the toilet.", but then a bug was found because the guest should have said "I do not need to go to the toilet.", the current policy is to change STR_1234.

I suggest to NOT do that and instead add a new string ID. Also, the old string ID should be considered deprecated from that point on and should no longer be used by the game anywhere.

Policy rules

The policy rule should state that whenever a string was changed, by default a new string ID should be used, and the old string ID must be deprecated.

There could be a list somewhere that lists all deprecated string IDs.

In some narrow cases, an exception is permissible when the meaning of the original string did not change and the overall change is very small. For example, a typo fix in the original string would not require a new string ID, unless the typo was a word with a different meaning. However, this exception should be used with care.

Why?

If you change the meaning of an existing string (for example, into it's complete opposite), this creates a huge problem for languages that have translated the old string. Because the old translation remains at the string ID, this means that suddenly, a wrong translation with the wrong meaning will appear in the game, with no fault of the translator. A translation that was correct before suddenly broke. This is bad.

Only with GitHub issues do we keep track of changing strings, but this approach is error-prone. It is very possible some outdated translations linger in the game and we have no idea they're outdated because we accidentally lost track of them.

In gettext-based programs, any string that was changed is usually kept in the files for reference, but is marked as outdated; the new string always starts untranslated or with a fuzzy translation (a translation that is incomplete and hasn't been verified yet and will be ignored by the program for now).

Is this possible?

TBH, I don't know if this policy is even possible. Is it reasonable to deprecate string IDs or are some string IDs so deeply hardcoded into the game they cannot be deprecated ever? If that's the case, then this whole suggestion admittedly falls apart.

Longterm solution

In the longterm, I wish OpenRCT2 just switches to gettext, because it doesn't have this problem to begin with and is way more robust and battle-tested. But that's of course much more complicated to do.

[tygrysek90]

I will just answer few questions for the OP:

As to possibility, string IDs get translated to human-readable constants for use in code such as e.g. STR_ADJUST_LARGER_LAND_TIP, outline of this process is briefly discussed in https://github.com/OpenRCT2/Localisation/wiki/Language-files#advanced .

I have not seen code having "magic numbers", but rather using named constants for strings - (i believe with current state of project there are no magic numbers = no hard-coding) ... and there should not be any completely hard-coded strings (untranslatable) as well, I found one few weeks ago and it is translatable ever since.

There actually exits a few string numbers that are already dropped - although there is a case where dropped string number that was translated, but not used in the code was repurposed back again, as shown in OpenRCT2/OpenRCT2#24827

[Wuzzy2]

Oh, I just assumed those numeric string IDs are used in code as well.

But still, I remember that it happened a few times here that the content of a numeric string ID has been changed including it's meaning. In one case, the meaning changed into the opposite.

So my core concern still stands, I think.

[Sadret]

I support this, examples where this happened are #2264 and #3108 .