Difference between revisions of "Translation"

From Minetest Developer Wiki
Jump to navigation Jump to search
Line 25: Line 25:
 
== How to merge translations from hosted weblate ==
 
== How to merge translations from hosted weblate ==
  
Translations should be merged in bulk, and not too often, to not create too large "noise" in the commit log. A good schedule is once per month. Right now, est31 manages translations. This section explains the neccessary steps for core devs, in the case est31 isn't around. You will need owner access to the hosted repo though, in order to be abled to push the "Rebase" button.  As of Mar 2017, est31, PilzAdam, ShadowNinja, and nerzhul have such access.
+
Translations should be merged in bulk, and not too often, to not create too large "noise" in the commit log. A good schedule is once per month. Right now, nerzhul manages translations. This section explains the neccessary steps for core devs, in the case nerzhul isn't around. You will need owner access to the hosted repo though, in order to be able to push the "Rebase" button.  As of Mar 2017, est31, PilzAdam, ShadowNinja, and nerzhul have such access.
  
 
=== Setting up ===
 
=== Setting up ===

Revision as of 15:29, 19 March 2017

Quick start

Translations of Minetest are automated using weblate at here.

In case you wish to translate a new language, contact a core dev.

Language specific notes

Here is a list of wiki pages for translating specific languages:

Overview

Minetest can use the gettext library to translate in-game text. To enable internationalization support, the game must be built with the -DENABLE_GETTEXT=1 option to cmake.

Language detection

Minetest detects the current language by inspecting the LANG environment variable. This is not a problem on Unix-based systems (such as GNU/Linux) since the system already defines this variable at login. On Windows platforms, the system language is used.

Available translations

The available translations are found in source form in the po/ directory. The cmake detects them, and they are built as part of the build process.

Contributing a new translation

To create a new translation, one must create a directory named after the language code, creating a copy of the po/minetest.pot file as po/LANG/minetest.po, and translating the original english text into your language; then cmake will detect it and make builds the language.

However, it is recomended to contact a core dev to create the .po file for you language and then use weblate to translate.

How to merge translations from hosted weblate

Translations should be merged in bulk, and not too often, to not create too large "noise" in the commit log. A good schedule is once per month. Right now, nerzhul manages translations. This section explains the neccessary steps for core devs, in the case nerzhul isn't around. You will need owner access to the hosted repo though, in order to be able to push the "Rebase" button. As of Mar 2017, est31, PilzAdam, ShadowNinja, and nerzhul have such access.

Setting up

Add weblate as remote: git remote add weblate git://git.weblate.org/minetest.git.

Once every translation

1. Visit Repo maintenance, and lock the repository to prevent changes from users while you are editing.

2. Generate a clean history, without merge commits. Push the "Rebase" button on the repository.

2. Do git remote update weblate. Confirm e.g. with gitk weblate/master that it bases on upstream's master, and only has "Translated using Weblate" as additional commits, no merge commits.

3. As every weblate user can freely edit translations, there can be vandalism. Therefore, check the translation commits, e.g. with help from online translator services like google translate, other core devs, or trusted members from the community. It might be helpful to push the commits to your github clone's branch, then you have commit http links to share. In the case of required changes, let them do it over the weblate interface (after you've unlocked), and start with 1. again. Of course, its up to you to how much you want to follow this rule, as checking changes can be quite time consuming. Feel free to refine your scope e.g. to new and not yet trusted contributors.

4. Reorder the commits from the same author, and squash them. git rebase -i is your friend (especially after you set it up to show the author, see this stackoverflow answer on how to do it). As a good tip, rather do multiple runs of such an interactive rebase where you do small changes each, than one big run which then fails in the middle of the business.

5. Confirm that git diff weblate/master is empty, to make sure that you didn't mess up at step 4. Otherwise use git reflog to find the latest rebase pass that worked, and retry the commits

6. a) (if required/desired) update the settingtypes.txt and the dummy cpp translation file and commit. There are automatic tools for this in the main menu code.

6. b) (if required/desired) Run util/updatepo.sh, and commit. Note that it creates lots of unneccessary changes, and enlarges repository size disproportionately, therefore run it even less often.

7. Push to the github repo

8. reset the weblate remote ("reset" button), rebase it to match now current master, and unlock it.