Simplified multilingualism for the development of new extensions

[FSharpCSharp]

We have now noticed a decisive disadvantage in creating the new apps. The use of the previous ML texts is no longer as intuitive as it was in the old development environment. Moreover, it is now very quickly becoming confusing if you use more than 5 languages. In addition, unattractive breaks can occur with very long texts.

So here's the idea: Introduction of a new object type "Translation". This object type should work similarly to the. NET world, managing resources with the. resx files. The advantage of the solution would be that all translations would have to be maintained centrally and in a single place. In addition, it would be very easy to see if a translation is missing somewhere. Furthermore, this list could be given to translation agencies and imported again.

[Gallimathias]

A solution to the problem has already been discussed and accepted in #229. ML is outdated in the long term and the outsourcing is done in Json files.

[StanislawStempin]

As described in #229 we are moving the localized texts out of the source code. Our current plan is to use XLIFF files since it is an open standard with rich tooling support. We'd be interested to hear your feedback about the choice of this file format.

[Gallimathias]

@StanislawStempin So outsourcing the translation is very good.

XLIFF is ok as format, but I personally wouldn't prefer it because I'm not a big fan of XML.

Personally, I would use a JSON file with minimal overhead.

{
  "ID": 90000,
  "Type": 1,
  "Name": {
    "ENU": "Data",
    "DEU": "Daten"
  },
  "Fields": [
    {
      "ID": 1,
      "Caption": {
        "ENU": "No.",
        "DEU": "Nr."
      }
    },
    {
      "ID": 2,
      "Caption": {
        "ENU": "Description",
        "DEU": "Beschreibung"
      }
    }
  ]
}

[FSharpCSharp]

@StanislawStempin Thank you for the information. It's good to hear that Microsoft wants to use an open standard for translations. Therefore, it should not be a problem to exchange the data with a translation agency. Is there already a closer planning for when the standard should be implemented, and is it planned that Microsoft will provide tools to automatically convert existing translations to the new format? If you do this manually for the first time, it is indeed a very big effort.

[StanislawStempin]

The new translation format should be available by the end of the year. We currently don't have plans for building the converter tool but perhaps this is a good area to create an open source tool with community participation.

[StanislawStempin]

@Gallimathias - while we also like JSON, the problem with inventing our own format is that there would be no tooling support for it in the translation ecosystem. Picking one of the existing formats ensures that it is already well supported by many tools/vendors.

[FSharpCSharp]

@StanislawStempin That sounds really good! I think it's great that Microsoft's suggestion comes from here to build a tool with the community directly.

[Gallimathias]

@StanislawStempin

Yes, but for JSON the tools are quickly assembled. Perhaps we can create a standard with a JSON format that could establish itself elsewhere. I have never used XLIFF before. If XLIFF comes then the overhead should be as small as possible.

I think it's just as cool as @FSharpCSharp that Microsoft wants to develop such a tool with the community. I'd like to be there. That sounds like a cool, smart task. Maybe I can do a little bit of the development in my livestream, which would be especially cool

[Gallimathias]

A small addition: JSON is also used as a standard. Wikimedia, for example, uses JSON with an open format.

I've made XLIFF too complex for our purposes. In addition, JSON as a language format is better suited for the web, since JavaScripts are already available and JSON is easy to process everywhere else. With XLIFF I have to search for a library or a framework. Or I study the specification first and then have to write it myself. In addition, you can also write JSON in a very simple way without a tool, with XLIFF it gets more complicated. I think XLIFF is too much.

Wikimedia: jQuery. i18n

[StanislawStempin]

We've looked into jQeury.i18n but it doesn't seem to have broad support, it seems to be only used by WikiMedia. Considering broad industry and tooling support we are going with XLIFF 1.2 format. Eventually we can add support for more localization file formats if there is such a need.

[Gallimathias]

@StanislawStempin Then thank you for your answer.

Ok, Let's try XLIFF.