1413514 - Use project configs in migrations

Status: RESOLVED WONTFIX

(Localization Infrastructure and Tools :: Fluent Migration, enhancement)

Description

[Axel Hecht [:Pike]]

How about using the project config code with the toml files to map reference and localization files?

We could use match() to get reference and localized file from a toml config.

That would make it somewhat possible to have a switch in the migration code to use en-US as reference, for sanity checking. Also, we'd only have to specify the localized file once.

And, I hope, it would enable us to use the migration code in non-Firefox projects easily.

stas?

Comment 1

[Staś Małolepszy :stas]

I'm not sure the benefits outweigh the cost of implementation and the increased complexity of testing the current migration code in python-fluent. We'd need to mock project configs for tests. It would also introduce one more dependency and abstraction layer. I'm not opposed to it but I'd like to better understand how you'd imaging the developer workflow to look like.

Right now, it's already possible to clone gecko-strings and run a migration against it:

    ./migrate-l10n.py --lang en-US --reference-dir examples --localization-dir ~/moz/gecko-strings examples.about_dialog

This creates browser/about_dialog.ftl in gecko-strings. Its contents are not byte-to-byte the same with the about_dialog.ftl in the examples/ directory because of the lossy-ness of serialization. But running compare locales between mozilla-central and gecko-string works fine. It's a bit clunky because of how it takes the l10n base and a locale code, but it works:

    compare-locales browser/locales/l10n.toml .. gecko-strings

Comment 2

[Axel Hecht [:Pike]]

It'd simplify the migrations, I'd say:

ctx.add_target('browser/locales/en-US/browser/preferences/main.ftl')
ctx.add_source('browser/locales/en-US/chrome/browser/preferences/main.dtd')
ctx.add_source('browser/locales/en-US/chrome/browser/preferences/main.properties')

and it would use the config to find the l10n files for that. And we could do that for the reference with the same data source as for a localization. If we want to avoid lengthy argument names, we could add nick-names for files.

Note, in mozilla-central, the paths might not be short anyway, depending on where we land the actual migration modules.

Also, we had more liberty in where to put the migration modules if the paths weren't relative to where those land.

The current setup doesn't allow for migrations to projects that use file.pl.ftl patterns, too.

Comment 3

[Eemeli Aro [:eemeli]]

Closing this as WONTFIX, as updating the API this way at this point would be more distracting than useful to users.