Move locale resources from Transifex to Pontoon

[alicoding]

We currently using .JSON and the file is being translated on Transifex. We should convert it to .property and move them to Pontoon.

[Pomax]

Going to be contrary here - Slowparse itself should stay JSON. The library has no front end, so tying this directly to Pontoon makes very little sense, which is for user facing front-end content translation. We can trivially add a .property to/from .json conversion somewhere (new npm package?) and then use that.

[alicoding]

As long as we have a repo with .property files for Pontoon to read and commit to then I don't mind a separate one.

[Pomax]

I just question the logic of using pontoon for Slowparse here. I understand pontoon for front-end, but this is a relatively static library, with static translations. Why would we go with pontoon for localizing in this instance?

[Pomax]

another option is to take actual full text errors out of slowparse, and instead make it return error codes (or objects with just the error code, and params object that contains things like cursor position and marks), so that consumers that use slowparse can resolve those to whatever text they like in their own code. Then pontoon probably makes sense because the error text would be in people's own applications, like in Thimble etc.

[alicoding]

I'm not sure if I understand your first question right, but we are using Pontoon because it's Mozilla's internal project and the community that helps the translation comfortable more of using this project than other one. Pontoon offers really nice front end solution but still works really well for library with no fronend like this one.

[Pomax]

yes I know, but Pontoon is for translating front-end technologies and slowparse is mostly a library. It has no "own page" where people can translate the strings, and doing the translation "through" something like thimble doesn't make a lot of sense, since Thimble does not own the slowparse strings so I don't understand why, or how, Pontoon would work here. Unless we offload string responsibility to Thimble, and have slowparse throw pure errors (with codes and event data, but without preassembled strings)