From 645ccba0f25fd5e123994f8ab1b3a02d9b8074b5 Mon Sep 17 00:00:00 2001 From: Dave Whiteland Date: Tue, 24 Jun 2014 13:11:38 +0100 Subject: add i18n page (from wiki) to dev docs --- docs/developers/i18n.md | 143 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 143 insertions(+) create mode 100644 docs/developers/i18n.md (limited to 'docs/developers') diff --git a/docs/developers/i18n.md b/docs/developers/i18n.md new file mode 100644 index 000000000..480d0d954 --- /dev/null +++ b/docs/developers/i18n.md @@ -0,0 +1,143 @@ +--- +layout: page +title: Internationalisation (for devs) +--- + +# Internationalisation in the code + +

+ This page describes some technical aspects of internationalising the + Alaveteli code. It's mostly aimed at devs who are working on the + codebase — if you just want to translate Alaveteli into your + own langauge, see this page on + Translating Alaveteli + instead. +

+ + +## Deployment notes + +Deployed translations for the project live in ``locale/``. + +Translations live in the project page at +[Transifex](https://www.transifex.net/projects/p/alaveteli/) and should +be submitted there. + +To deploy, say, English and Spanish translations at once: + + * Ensure their PO files are at ```locale/en/app.po``` and ```locale/es/app.po``` + (for example, by downloading them from Transifex) + * Set AVAILABLE_LOCALES + to en es + +The ``pot``-file at ``locale/app.pot`` acts as the template for PO files. When +new translation strings have been added to the source, this ``pot``-file can be +updated using the script at ``script/generate_pot.sh``. This looks for new +translatable strings in the source and creates entries in the ``pot``-file. + +For more details about the translations, see the page about +[translating Alaveteli]({{ site.baseurl }}customising/translation). + + +## Technical implementation details + +### Getting the current locale + +This is complicated by the fact that there are two competing ways to define a +locale+territory combination. The POSIX (and `gettext` and Transifex) way is +like `en_GB`; the Rails way is like `en-US`. Because we are using gettext and +Transifex for translations, we must deal with both. Wherever you need to know +the Rails version of the currently selected locale, use `I18n.locale`; wherever +you want to know the POSIX version of the locale, use `FastGettext.locale`. + +## I18n in templates + +Before you add i18n strings to the source, you should read +[internationalisation guidelines](http://mysociety.github.io/internationalization.html) +that apply to all our projects. + +Some hints for adding the strings into the Alaveteli code: + +* Simple strings: ```<% = _("String to translate") %>``` +* Strings that include variables: give the translator a hand by inserting + strings that can be interpolated, so the variable has meaning. For example, + ```<%= "Nothing found for '" + h(@query) + "'" %>``` might become ```<%= + _("Nothing found for '{{search_terms}}'", :search_terms => h(@query)) %>``` +* Strings containing numbers: ```<%= n_('%d request', '%d requests', @quantity) % @quantity %>``` +* We allow some inline HTML where it helps with meaningful context, for example: + +``` +_('Browse all or ask us to add it.', + :browse_url => @browse_url, :add_url => @add_url) +``` + +Similar rules can apply to strings in the python source code, as long as you +import ```_```, ```n_```, etc. + +## Programmatic access of translated PublicBodies + +Apart from the templates, the only other area of i18n currently implemented is +in the PublicBodies. + +The implementation allows for getting different locales of a PublicBody like so: + +```ruby + PublicBody.with_locale("es") do + puts PublicBody.find(230).name + end +``` + +Usually, that's all the code you need to know about. There's a method +```self.locale_from_params()``` available on all models which returns a locale +specified as ```locale=xx``` in the query string, and which falls back to the +default locale, that you can use in conjunction with the ```with_locale``` +method above. All the joining on internal translation tables should usually be +handled automagically -- but there are some exceptions, that follow below. + +### Overriding model field setters + +Internally, we use the [Globalize plugin](https://rubygems.org/gems/globalize) +to localize model fields. Where column "foo" has been marked in the model as +```:translates```, globalize overrides ```foo.baz = 12``` to actually set the +value in column ```baz``` of table ```foo_translations```. + +A side effect of the way it does this is that if you wish to override a +specific attribute setter, you will need to explicitly call the Globalize +machinery; something like: + +```ruby + def name=(name) + globalize.write(self.class.locale || I18n.locale, "name", name) + self["name"] = short_name + # your other stuff here + end +``` + +### Searching + +The ```find_first_by_``` and ```find_all_by_``` magic methods +should work. If you want to do a more programmatic search, you will need to +join on the translation table. For example: + +```ruby + query = "#{translated_attr_name(someattr) = ? AND #{translated_attr_name('locale')} IN (?)" + locales = Globalize.fallbacks(locale || I18n.locale).map(&:to_s) + find( + :first, + :joins => :translations, + :conditions => [query, value, locales], + :readonly => false + ) +``` + +You may also need to do some lower-level SQL joins or conditions. See +```PublicBodyController.list``` for an example of a query that has a condition +that is explicitly locale-aware (look for the ```locale_condition``` variable) + + +## I18n in URLs + +We have tried using the [translate_routes plugin](https://github.com/raul/translate_routes) +to localize URLs. This looks up URL segments as translation strings in a YAML +file at```config/i18n-routes.yml```. However, we no longer use it because we +found it was overly complex. -- cgit v1.2.3 From 1ec977edae73b9257f9e93fe2475f861e1023274 Mon Sep 17 00:00:00 2001 From: Dave Whiteland Date: Tue, 24 Jun 2014 13:19:04 +0100 Subject: move release manager note (needs more work) --- docs/developers/i18n.md | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) (limited to 'docs/developers') diff --git a/docs/developers/i18n.md b/docs/developers/i18n.md index 480d0d954..34ef2a28c 100644 --- a/docs/developers/i18n.md +++ b/docs/developers/i18n.md @@ -10,11 +10,10 @@ title: Internationalisation (for devs) Alaveteli code. It's mostly aimed at devs who are working on the codebase — if you just want to translate Alaveteli into your own langauge, see this page on - Translating Alaveteli + translating Alaveteli instead.

- ## Deployment notes Deployed translations for the project live in ``locale/``. @@ -134,6 +133,13 @@ You may also need to do some lower-level SQL joins or conditions. See ```PublicBodyController.list``` for an example of a query that has a condition that is explicitly locale-aware (look for the ```locale_condition``` variable) +## Translation and releases + +The release manager will enforce a translation freeze just before a new release +is cut. During such time, you must not introduce new strings to the code if +your work is due for inclusion in this release. This is necessary to allow +translators time to complete and check their translations against all the known +strings. ## I18n in URLs -- cgit v1.2.3 From a662f2ae1a7dbfc40621abbb6b779aad2f01e142 Mon Sep 17 00:00:00 2001 From: Dave Whiteland Date: Tue, 24 Jun 2014 14:58:13 +0100 Subject: rewrite bad sentence/spelling --- docs/developers/i18n.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'docs/developers') diff --git a/docs/developers/i18n.md b/docs/developers/i18n.md index 34ef2a28c..67e7e5be8 100644 --- a/docs/developers/i18n.md +++ b/docs/developers/i18n.md @@ -9,7 +9,7 @@ title: Internationalisation (for devs) This page describes some technical aspects of internationalising the Alaveteli code. It's mostly aimed at devs who are working on the codebase — if you just want to translate Alaveteli into your - own langauge, see this page on + own language, see translating Alaveteli instead.

-- cgit v1.2.3 From 36ccd092d91da93774979d445203c29156880079 Mon Sep 17 00:00:00 2001 From: Dave Whiteland Date: Wed, 25 Jun 2014 17:30:24 +0100 Subject: fix broken links --- docs/developers/i18n.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'docs/developers') diff --git a/docs/developers/i18n.md b/docs/developers/i18n.md index 67e7e5be8..51d6cada1 100644 --- a/docs/developers/i18n.md +++ b/docs/developers/i18n.md @@ -26,7 +26,7 @@ To deploy, say, English and Spanish translations at once: * Ensure their PO files are at ```locale/en/app.po``` and ```locale/es/app.po``` (for example, by downloading them from Transifex) - * Set AVAILABLE_LOCALES + * Set AVAILABLE_LOCALES to en es The ``pot``-file at ``locale/app.pot`` acts as the template for PO files. When @@ -35,7 +35,7 @@ updated using the script at ``script/generate_pot.sh``. This looks for new translatable strings in the source and creates entries in the ``pot``-file. For more details about the translations, see the page about -[translating Alaveteli]({{ site.baseurl }}customising/translation). +[translating Alaveteli]({{ site.baseurl }}docs/customising/translation/). ## Technical implementation details @@ -95,7 +95,7 @@ handled automagically -- but there are some exceptions, that follow below. ### Overriding model field setters -Internally, we use the [Globalize plugin](https://rubygems.org/gems/globalize) +Internally, we use the [Globalize plugin](https://github.com/globalize/globalize) to localize model fields. Where column "foo" has been marked in the model as ```:translates```, globalize overrides ```foo.baz = 12``` to actually set the value in column ```baz``` of table ```foo_translations```. -- cgit v1.2.3 From 07d6c2f5667b45db22b8426ce0f4c948fb3c8cec Mon Sep 17 00:00:00 2001 From: Dave Whiteland Date: Wed, 25 Jun 2014 17:33:05 +0100 Subject: rewrites and fixes --- docs/developers/i18n.md | 31 +++++++++++++++---------------- 1 file changed, 15 insertions(+), 16 deletions(-) (limited to 'docs/developers') diff --git a/docs/developers/i18n.md b/docs/developers/i18n.md index 51d6cada1..521ca5768 100644 --- a/docs/developers/i18n.md +++ b/docs/developers/i18n.md @@ -22,17 +22,23 @@ Translations live in the project page at [Transifex](https://www.transifex.net/projects/p/alaveteli/) and should be submitted there. -To deploy, say, English and Spanish translations at once: +For example, to deploy English and Spanish translations at once: * Ensure their PO files are at ```locale/en/app.po``` and ```locale/es/app.po``` (for example, by downloading them from Transifex) * Set AVAILABLE_LOCALES to en es - -The ``pot``-file at ``locale/app.pot`` acts as the template for PO files. When -new translation strings have been added to the source, this ``pot``-file can be -updated using the script at ``script/generate_pot.sh``. This looks for new -translatable strings in the source and creates entries in the ``pot``-file. + +To update the `.pot` and `.po` files for each language, run: + + bundle exec rake gettext:store_model_attributes + +followed by: + + bundle exec rake gettext:find + +If `gettext:find` only creates the file `locale/im-config.pot` then you need to +unset the `TEXTDOMAIN` environment variable and try again. For more details about the translations, see the page about [translating Alaveteli]({{ site.baseurl }}docs/customising/translation/). @@ -43,7 +49,7 @@ For more details about the translations, see the page about ### Getting the current locale This is complicated by the fact that there are two competing ways to define a -locale+territory combination. The POSIX (and `gettext` and Transifex) way is +locale+territory combination. The POSIX (and gettext and Transifex) way is like `en_GB`; the Rails way is like `en-US`. Because we are using gettext and Transifex for translations, we must deal with both. Wherever you need to know the Rails version of the currently selected locale, use `I18n.locale`; wherever @@ -70,8 +76,7 @@ _('Browse all or ask us to ad :browse_url => @browse_url, :add_url => @add_url) ``` -Similar rules can apply to strings in the python source code, as long as you -import ```_```, ```n_```, etc. +Similar rules can apply to strings in the Ruby source code. ## Programmatic access of translated PublicBodies @@ -139,11 +144,5 @@ The release manager will enforce a translation freeze just before a new release is cut. During such time, you must not introduce new strings to the code if your work is due for inclusion in this release. This is necessary to allow translators time to complete and check their translations against all the known -strings. - -## I18n in URLs +strings. See more about [translating Alaveteli]({{ site.baseurl }}docs/customising/translation/). -We have tried using the [translate_routes plugin](https://github.com/raul/translate_routes) -to localize URLs. This looks up URL segments as translation strings in a YAML -file at```config/i18n-routes.yml```. However, we no longer use it because we -found it was overly complex. -- cgit v1.2.3 From 230b2fee5ddf656344bfac53dea7f2a10c6c0a4b Mon Sep 17 00:00:00 2001 From: Dave Whiteland Date: Thu, 3 Jul 2014 12:54:24 +0100 Subject: rewritten i18n/translation pages with @crowbot's comments in mind --- docs/developers/i18n.md | 29 +++++++++++++++++++++-------- 1 file changed, 21 insertions(+), 8 deletions(-) (limited to 'docs/developers') diff --git a/docs/developers/i18n.md b/docs/developers/i18n.md index 521ca5768..deabc99a1 100644 --- a/docs/developers/i18n.md +++ b/docs/developers/i18n.md @@ -18,18 +18,30 @@ title: Internationalisation (for devs) Deployed translations for the project live in ``locale/``. -Translations live in the project page at -[Transifex](https://www.transifex.net/projects/p/alaveteli/) and should -be submitted there. +We encourage translations to be done on +[Transifex](https://www.transifex.net/projects/p/alaveteli/) +because translators can work through its web interface rather than needing to edit the +`.po` and `.pot` files +directly. Ultimately, Transifex just captures translators' +work and turns it into the files that Alaveteli needs (using gettext). + +### How to get the latest translations onto your site For example, to deploy English and Spanish translations at once: - * Ensure their PO files are at ```locale/en/app.po``` and ```locale/es/app.po``` + * Ensure their `.po` files are at ```locale/en/app.po``` and ```locale/es/app.po``` (for example, by downloading them from Transifex) * Set AVAILABLE_LOCALES to en es -To update the `.pot` and `.po` files for each language, run: +### How to add new strings to the translations + +You need to do this if you've added any new strings to the code that need +translations (or if you change an existing one). + +To update the +`.po` or `.pot` files +for each language, run: bundle exec rake gettext:store_model_attributes @@ -51,9 +63,10 @@ For more details about the translations, see the page about This is complicated by the fact that there are two competing ways to define a locale+territory combination. The POSIX (and gettext and Transifex) way is like `en_GB`; the Rails way is like `en-US`. Because we are using gettext and -Transifex for translations, we must deal with both. Wherever you need to know -the Rails version of the currently selected locale, use `I18n.locale`; wherever -you want to know the POSIX version of the locale, use `FastGettext.locale`. +Transifex for translations, we must deal with both. + + * for the Rails version of the currently selected locale, use `I18n.locale` + * for the POSIX version of the locale, use `FastGettext.locale` ## I18n in templates -- cgit v1.2.3