Opened 5 years ago

Closed 4 years ago

#2109 closed change (fixed)

Generalize translations and allow translating app-independent repositories

Reported by: trev Assignee: kzar
Priority: P2 Milestone:
Module: Automation Keywords:
Cc: sebastian Blocked By:
Blocking: #2834 Platform: Unknown
Ready: yes Confidential: no
Tester: Unknown Verified working: no
Review URL(s):

http://codereview.adblockplus.org/5944359652425728/
https://codereview.adblockplus.org/29336281/

Description (last modified by kzar)

Background

With adblockplusui we have the first repository with localization that isn't tied to a specific platform. Currently we have no good way to translate files in this repository.

What to change

The way I see it, we currently deduce the following parameters from the platform:

  • Locales directory path (_locales vs. chrome/locale)
  • Format of the locale identifiers (ISO-15897 with variations like es_419 vs. BCP-47)
  • Format of the localization files (Chrome-like JSON vs. DTD)
  • Platform-specific list of available locales
  • Default locale

For a more generic localization approach we need to introduce these parameters in the metadata file:

[locales]
base_path =_locales
name_format = BCP-47
file_format=chrome-json
target_platforms=chrome firefox
default_locale = en-US

All these parameters should be optional if they can be deduced from the platform. However, adblockplusui repository should get a metadata.generic file and they should be mandatory there.

Change History (13)

comment:1 Changed 5 years ago by sebastian

  • Blocking 1205 added
  • Priority changed from Unknown to P2
  • Ready set

comment:2 Changed 5 years ago by trev

  • Review URL(s) modified (diff)

This will involve lots of refactoring so I will try to break the changes down into small chunks. The first chunk is under review, more will come.

comment:4 Changed 4 years ago by greiner

  • Blocking 2834 added

comment:5 Changed 4 years ago by greiner

  • Blocking 1205 removed

comment:6 Changed 4 years ago by kzar

  • Owner changed from trev to kzar
  • Tester set to Unknown
  • Verified working unset

comment:7 follow-up: Changed 4 years ago by kzar

  • Ready unset

Two questions:

  • Does anyone know which format Chrome and Firefox use for locale identifiers? (From the description it implies that Chrome uses ISO-3166 and Firefox uses BCP 47, but isn't ISO-3166 for countries not languages?)
  • What is the function of the possible_locales field? (I'm guessing the example in the issue description is a typo and instead of having a value like chrome firefox it should instead have a list of locales like en_US and de?)

comment:8 in reply to: ↑ 7 ; follow-up: Changed 4 years ago by sebastian

Replying to kzar:

  • Does anyone know which format Chrome and Firefox use for locale identifiers? (From the description it implies that Chrome uses ISO-3166 and Firefox uses BCP 47, but isn't ISO-3166 for countries not languages?)

Yes, that isn't accurate. Chrome uses lang[_region] where lang is an ISO 639-1 code. And region, if given, is an ISO 3166-1 alpha 2 code, with the exception of es-419.

  • What is the function of the possible_locales field? (I'm guessing the example in the issue description is a typo and instead of having a value like chrome firefox it should instead have a list of locales like en_US and de?)

I'm guessing that possible_locales=chrome firefox is a shorthand for all locales supported by either Chrome and Firefox. But I'm not entirely sure either, and yes that should probably have been specified more precisely in the issue description.

comment:9 in reply to: ↑ 8 Changed 4 years ago by kzar

Replying to sebastian:

Yes, that isn't accurate. Chrome uses lang[_region] where lang is an ISO 639-1 code. And region, if given, is an ISO 3166-1 alpha 2 code, with the exception of es-419.

Any objection to just using the strings gecko or chrome to describe the locale name format instead? I don't think something like iso-639-1+iso3166-1ish is very catchy.

I'm guessing that possible_locales=chrome firefox is a shorthand for all locales supported by either Chrome and Firefox. But I'm not entirely sure either, and yes that should probably have been specified more precisely in the issue description.

Yea, I'm still not clear on that one either. I guess for now I'll make the logic as follows:

  1. If the field is specified, use the locales given.
  2. If the field is not specified and type is gecko, call buildtools.packagerGecko.getLocales
  3. Otherwise just use a directory listing of the specified locales directory.

comment:10 Changed 4 years ago by trev

  • Description modified (diff)

I actually meant names to be a more objective description of the format than "whatever Google chose to use right now." You are right, ISO-3166 isn't the correct term - it's rather ISO-15897, or maybe just POSIX.

possible_locales on the other hand is the list of available locales and this one is specific to the particular platform. Our locale tools currently know how to calculate the list of locales for Firefox and Chrome. This isn't really important for packaging, rather for setting up Crowdin projects - we have to know which languages we need.

Last edited 4 years ago by trev (previous) (diff)

comment:11 Changed 4 years ago by kzar

  • Description modified (diff)
  • Ready set

comment:12 Changed 4 years ago by kzar

  • Review URL(s) modified (diff)
  • Status changed from new to reviewing

comment:13 Changed 4 years ago by kzar

  • Description modified (diff)
  • Resolution set to fixed
  • Status changed from reviewing to closed
Note: See TracTickets for help on using tickets.