Skip to content
Ríša Szlachta edited this page Aug 20, 2025 · 7 revisions

This article contain welcome level information aimed at persons not familiar with GitHub and general idea of concurrent version systems, as well it descbires purely web-browser based approach, without using intricate command line tools such as git.

For peoples familiar with those, recommended reading materials are README.md and GitHub official forking guide

Prerequisites

First of all, a user needs to have been created a GitHub account and logged in.

Forking a repository

A repository (🔗 Wikipedia), in this case OpenRCT2/Localisation needs to forked first. Forking refers to creating a copy of repository under individual user (translator's) account, where modifications can be done freely without affecting the repository it has been forked from.

zmenšit

Once the repository is forked, an translator can verify it's presence in the fork by looking in top left corner of the page, which now displays own user name / Localisation, and below displays "Forked from OpenRCT2/Localisation"

Snímek obrazovky z 2025-08-19 18-05-17

Branches

The branches refer to copies of given repository or it's fork, residing inside it. For Localisation, the main branch is called master. From master branch, translator can create a number of branches, each tackling something else. In usual work-set of established and maintained language, translator only creates one branch based on up-to-date master to apply new strings from last issue. However translator might need to fix a typo in a few already existing lines and thus chooses create another branch from master, where some typo fixes (for example) can be addressed.

g537

Creating a feature branch

To creating a branch in web-browser, once navigated to user's fork as described above, it is neccesary to navigate to branches page, which is done by clicking on "Branches" button:

Snímek obrazovky z 2025-08-18 18-18-28

Once on branches page, selecting "**New branch**" will bring up pop-up window prompting to enter branch name. It is wise to use meaningful names of branches, in order not to confuse one with each other.

479629133-13392b6d-01f1-460d-a8ba-40d798b20e82

When the branch is created, translator can simply navigate to a localisation file and choose pencil icon to edit given file:

zmenšit2

Committing

Saving changes in context of concurrent version systems is called committing. It is wise to enter commit title in style used in Localisation repository - discussed in detail in Localisation commit messages - using combined language code and description, e.g. de-DE: Apply #1234 or cs-CZ: Fix a typo, as this will later be used for Pull Request title, in usual case when there is only one commit per Pull Request.

zmenšit3

Pull Request

Once change is committed to a feature branch in forked repository, as described above, a Pull Request (shortened PR) can be opened. The PR is an kind of application translator submits to get changes into the Localisation repository (from which he or she forked before) and thus get them into the resulting game.

g537_2

To start creating a Pull request, translator navigates to main page of it's fork, and either can choose to "Compare & pull request" or "Contribute"

Snímek obrazovky z 2025-08-19 19-32-44

Review and merge

Waiting

Once the PR is created, translator needs to patiently wait for one of regular members of OpenRCT2 project to review and merge the PR. This process can take from less than one minute to a few days. Since this is open source project, the maintainers are doing all the work in their spare time, while working full time jobs and providing their families, hence there is no-one waiting 27/7 to accept PRs.

A list of Pull request waiting to be merged can be viewed under Pull requests tab on OpenRCT2 / Localisation repo page.

Snímek obrazovky z 2025-08-19 19-44-43

Review and possible follow-up

A core member of OpenRCT2 will review the Pull Request. This means mostly checking formalities, such as number of added lines and if the PR is named correctly. In rare case a mistake or problem is found, e.g. when applying issue with 10 new lines only 9 are added, the translator will notified (via comment and default also via email) and given options what can be done about the problem - there is no need to worry, everyone makes a mistakes. If changes are required, it is of course possible for translator to simply update the branch in the question - there is no need to close the PR and reopen it once again.

Merge

In case of extreme luck and providing PR is well formed and needs no changes, and given there is maintainer currently logged on and working on reviewing an merging, the PR can be merged in order of minutes, which earns the translator a badge on his/hers GitHub profile.

Snímek obrazovky z 2025-08-19 19-42-16

Keeping user's master up-to-date

As things get rolling, translator is making branches and submitting PRs, it is necessary to keep one's master branch up-to-date with upstream master (the master from OpenRCT2/Localisation). This is done to incorporate changes that were pulled into upstream via previously submitted PRs

g537_3

In web GitHub, this is done by simply navigating to fork, where can be observed "This branch is n commits behind", selecting "Sync fork" and "Update branch"

Snímek obrazovky z 2025-08-20 18-02-41


Footnotes: Inkscape scalable vector graphics files for graphs are attached into this page: commiting-basics.tar.gz md5sum 5ee164c9e4611b096d1b17ddbb7f163c

Clone this wiki locally