|Version 49 (modified by 9 years ago) ( diff ),|
Table of Contents
This page looks at ways we can extend the Internationalisation options within Sahana Eden.
Production Options are defined within DeveloperGuidelines/Internationalisation
User perspective is: UserGuidelines/Localisation
Below are some tasks that can help in improving the existing translation functionality.
- Pootle integration
- Deprecated strings must not be merged back into ".py" language files when merging from pootle.
- Setting up a separate sub-project on Pootle for a deployment
- Upload .po file
- from URL as well as file (e.g. http://pootle.sahanafoundation.org/pootle/export/eden/fr/fr.po)
- Add ability to enable/disable menu options (make this a DB table rather than a deployment_setting?)
- Think about how uploaded files can not conflict with updates from Version Control (currently uploaded updates will be wiped during upgrades)
- Exclude all templates other than current one by default (option to include all templates, defaulting to off)
- Default list of modules to the ones which are active in the running template
- List of modules shouldn't come from list of controllers (e.g. misses translate itself!)
Exclude Unit Tests folder Exclude all full paths (2nd occurrence+ is giving full path)
- Include certain prepop CSV columns (for T(record.field))
Don't include vars - e.g. T(r.name) shouldn't add "r.name" to the translation file
- Rewrite admin.py translate() so that only opt3 is a REST controller for translate_language (no need for an opt)
- All other opts should be separate controllers
- Online help to explain that the local languages/code.py will be updated & that uploaded files will be merged
- Online help to explain 'core files'
- Copy code from TranslateToolkit internally to avoid having external dependencies & launching a shell
- Extend web2py2po/po2web2py to support translator comments
def translate(self, message, symbols): """ user ## to add a comment into a translation string the comment can be useful do discriminate different possible translations for the same string (for example different locations) T(' hello world ') -> ' hello world ' T(' hello world ## token') -> 'hello world' T('hello ## world ## token') -> 'hello ## world' """
Different Sources of translated strings
There are mainly three sources of translated strings :-
1) Uploading CSV/PO file : In this case, the existing ".py" language file is merged with the translations from the uploaded files. Currently only upload of csv files is supported.
2) Through pull request : Translated strings are received through pull request.( One issue with the pull is that the Version control wipes out the uploaded updates.)
3) Through Pootle : This is in connection with the Pootle Integration of Sahana Eden. We need to be able to keep the Pootle and web2py language files in sync with respect to the strings. Hence, when merging with Pootle, there mustn't be any conflicts.
- Babel - good toolkit to combine with GNU/gettext
- LaunchPad Translations - access to Ubuntu community
- GoogleTranslate can be used to help translators get started, but needs humans to make cultural and linguistic refinements
- Web2Py plugin for this: http://www.web2py.com/plugins/default/translate
- Google ta3reeb - Arabic 'keyboard' using Latin characters
- MS Localisation Design Pattern: http://msdn.microsoft.com/en-us/library/dd129504%28v=VS.85%29.aspx
- If needing to be able to handle alternate word order with dynamic strings then wrap in XML():
- Databases store Unicode characters as 2+ bytes, so string, length=20 may limit to just 10 characters:
- UTF-8 encoding in Controllers:
- Date fields:
- Working across Timezones:
- Paragraph Translations:
- Currency Formatting:
- 18:48 onwards has relevant discussion...
- http://logs.sahanafoundation.org/sahana-eden/2013-04-19.txt (13:00 onwards)
- http://logs.sahanafoundation.org/sahana-eden/2013-04-22.txt (13:17 onwards)