Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
  • Is something wrong?
#3,331 3 comments 4 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
20/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Stale
Domain
internationalization, localization

Research direction

The issue names no files, tests, or entry points to modify. Start by determining how string IDs are stored, referenced, and translated, and whether deprecated IDs can be tracked safely. Done would require an agreed policy, an implementation path, and documented handling for changed strings and exceptions.

Written by the indexing model from the issue text.

Description

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.

Dominant language
No language data
Stars
71
Forks
212
Avg merge
17h 44m
Merged PRs (30d)
21

Getting set up

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from OpenRCT2/Localisation

All issues in OpenRCT2/Localisation

Similar issues

More Internationalization issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.