Add support for two letter ISO-639-1 language codes

[akincel]

Some other Cimpress related tools as Customizr work with two-letter ISO-639-1 language codes. Therefore adding support to this client removes the need to re-implement this mapping logic.

[istanishev]

Why would adding this avoid the mapping in clients that prefer to use the the short language codes?

[akincel]

Customizr (the generic MCP settings) works with 2 letter codes. Translations with 3 letter codes. We plan to make Translations work with 2 letter codes by default as well (while still leaving the option of 3 letter codes).

So how this helps? The clients just pass the language code they have in their application. For existing users of Translations, it is the 3 letter code. For the new users, it will be the 2 letter code.

Am I answering your question?

[istanishev]

Well, I understand the Customizr case (and not only), but this change only addresses the "discoverability" which might not be enough. What is important in some cases is to really use the languages that the service returns. And unless I miss something what will be returned both from the service and this client will be only the 3-letter language code.

There are multiple cases that do require additional processing of translations, but I think the most important one is translating components that require 'different' language codes and/or different logic to do so.

[akincel]

And unless I miss something what will be returned both from the service and this client will be only the 3-letter language code.

In my previous comment I tried to say, that Translations will start working with 2 letter language codes by default. So both the service and client will return 2-letter code.

Only for services which are already on 3-letter codes, it will keep them for backward compatibility reasons.

I can also add logic to convert the language codes in the response from Translations to 2-letter codes, if 2-letter code was used to invoke a method of this client. Would that be helpful?

[istanishev]

I'm not sure I understand the full scope of the change that is planned. Are you saying that:

1. The service will return 3-letter code for "old services" and 2-letter code for "new services"?
2. Are you planning to change the UI to also handle the 3-/2- letter conversion when pasting translations JSONs?

If the answer is yes, what is the timeline of these changes. Should the change of this client be the last thing?