1289705 - Add support for FTL files in Transvision

Status: RESOLVED FIXED

(L20n :: General, defect)

Description

[Francesco Lodolo [:flod]]

Per discussion on IRC with Stas, we also need to consider Transvision in the larger l20n picture. It's a tool used by several localization teams, and if it's not a blocker for deploying l20n initially, it's definitely a big concern.

Transvision uses a Python script based on Silme to extract strings
https://github.com/flodolo/tmx_maker

This script generates a PHP file with all strings stored as a PHP array.

Some thoughts:
* We need a parser for FTL. Having that in Silme would be ideal, since we need to keep it around for other formats. But Silme was marked as "to be killed" after last meeting in Stockholm. 
* We need to figure out how to store complex strings, e.g. traits. It probably make sense to store them as separate strings on Transvision's side.
* We need to figure out how to deal with complex strings, e.g. plural formats, variants, etc.

Comment 1

[Axel Hecht [:Pike]]

I agree that transvision support is good, but I don't think we should block on this. Removing the blocks for gecko-l20n.

Some technical comments:

* I don't think we should touch silme for this
* I think we have a cross-product interest in transforming l20n entities into something to be used for TM
* It'd make sense to me to add that to python-l20n

We're starting to gain some insights into how our ftl look with bug 1288406, that should inform us which task we actually need to solve.

Should we make this depend on a dedicated bug on the python library for "TM-focused API" ?

Should we have a decision bug on what we actually intend to do in the interaction between l20n and TM tools?

Comment 2

[Francesco Lodolo [:flod]]

There's a pull request, pending review, that adds basic support for FTL files, using compare-locales to parse them
https://github.com/mozfr/transvision/pull/924

It might not be elegant, but

foo = bar

is stored as file:foo internally (like it happens for a .properties file), while attributes are stored separately, e.g.

foo
  .label = bar
  .accesskey = b

is stored as two strings: file:foo.bar and file:foo.accesskey. This also give the advantage that all existing QA views (shortcut, accesskeys) justwork™.

In case of more complex strings (e.g. plural forms) the entire raw_val is stored.

Comment 3

[Francesco Lodolo [:flod]]

This landed in
https://github.com/mozfr/transvision/commit/00600cc0871d7f7a4a89c091a8a2a15aee51470c

There will still be work to do, mostly on the variables view, but this is good enough for now.