##// END OF EJS Templates
u » ewong » rhodecode-enterprise-ce-fork
RSS

Fork of rhodecode-enterprise-ce

vcs: Minimal change to expose the shadow repository...
vcs: Minimal change to expose the shadow repository Based on my original research, this was the "minimal" starting point. It shows that three concepts are needed for the "repo_name": * From the security standpoint we think of the shadow repository having the same ACL as the target repository of the pull request. This is because the pull request itself is considered to be a part of the target repository. Out of this thought, the variable "acl_repo_name" is used whenever we want to check permissions or when we need the database configuration of the repository. An alternative name would have been "db_repo_name", but the usage for ACL checking is the most important one. * From the web interaction perspective, we need the URL which was originally used to get to the repository. This is because based on this base URL commands can be identified. Especially for Git this is important, so that the commands are correctly recognized. Since the URL is in the focus, this is called "url_repo_name". * Finally we have to deal with the repository on the file system. This is what the VCS layer deal with normally, so this name is called "vcs_repo_name". The original repository interaction is a special case where all three names are the same. When interacting with a pull request, these three names are typically all different. This change is minimal in a sense that it just makes the interaction with a shadow repository barely work, without checking any special constraints yet. This was the starting point for further work on this topic.
marcink - - Load All Authors

File last commit:

r1:854a839a default
r887:175782be default
Show More
how_to.rst
136 lines | 3.7 KiB | text/x-rst | RstLexer
/ rhodecode / i18n / how_to.rst
History | Annotation | Raw |Copy content |Copy permalink

To create a new language

Translations are available on transifex under:

https://www.transifex.com/projects/p/RhodeCode/

Log into transifex and request new language translation.

manual creation of new language

Step 1: If you don't have a dev environment set up, download sources of RhodeCode. Run:

python setup.py develop

Otherwise, update to the latest stable commit.

Note: The following commands are intended to be run in the main repo directory using Linux; running them in nix-shell is fine.

Step 2: Make sure all translation strings are extracted by running:

python setup.py extract_messages

Step 3: Create a new language by executing following command:

python setup.py init_catalog -l <new_language_code>

This creates a new language under directory rhodecode/i18n/<new_language_code>

Step 4: Be sure to update transifex mapping, located at rhodecode/.tx/config The path to the new language should be identical to the others, instead using the new language code.

Step 5: Verify the translation file and fix any errors. This can be done by executing:

msgfmt -f -c rhodecode/i18n/<new_language_code>/LC_MESSAGES/<updated_file.po>

Edit rhodecode/i18n/<new_language_code>/LC_MESSAGES/rhodecode.po for errors with your favorite file editor (the errors will tell you what's missing, check other rhodecode.po files in existing languages for clues).

Step 6: Finally, compile the translations:

python setup.py compile_catalog -l <new_language_code>

Note: Make sure there is not a .mo file in the top-level folder!

To update translations

Note: This is a different process, not needed when you are adding a translation.

Step 1: Fetch the latest version of strings for translation by running:

python setup.py extract_messages

Step 2: Update the rhodecode.po file using:

python setup.py update_catalog -l <new_language_code>

Step 3: Update the po file as outlined in step 5 for new translations (see above).

Step 4: Compile the translations as outlined in step 6 for new translations (see above).

Note: Make sure there is not a .mo file in the top-level folder!

Javascript translations

First find all translation used in JS by running the command:

grep "_TM[.*]" -R . -oh | sort -u

Then compare it against the file scripts/tasks/file_generation/js_i18n_data.py. Add or remove strings to that file remembering to add them surrounded by _(...), or otherwise they won't get added to the catalog.

In case the file changed, regenereate the catalog by following the instructions above ('to update translations').

Once the new strings were transalated and the catalogs comiled with msgfmt, you can generate the Javascript translation files. To do so, just run the command:

invoke -r scripts/ generate.js-i18n

Which will generate one JS file for detected language in the folder rhodecode/public/js/rhodecode/i18n/{lang}.js

Finally, commit the changes.

Testing translations

Edit the test.ini file, setting the lang attribute to:

lang=<new_language_code>

Run RhodeCode tests by executing:

nosetests

Workflow for Transifex

#0 new language:
edit .tx/config and add language
#1 extract messages to generate updated pot file
python setup.py extract_messages
#2 push source .pot file to Transifex
tx push -s
#3 when translations are ok pull changes
tx pull
#4 compile languages
python setup.py compile_catalog