Add option to mark names and strings as untranslatable

[1ec5]

Regional presets and fields need a flag to indicate that they shouldn’t be translated. For example, the German school types in openstreetmap/id-tagging-schema#331 have no natural English name, and it isn’t practically necessary to translate them. There should be a Boolean-typed i18n property to indicate to translators that they can simply copy the source string in Transifex. Unlike the i18n flag in editor-layer-index, this property would default to true, encouraging translation. This property could apply to strings as well, for tag values that need to be Title Cased but otherwise don’t need to be translated.

The schema builder compiles the JSON files into a YAML file, which can contain comments that appear as context in Transifex. The comment could read “Do Not Translate” when i18n is false, or there could be a more general, string-typed nameComment property.

[tyrasd]

I think it would be best to simply not include such strings in the to-be-translated interim/source_strings.yaml file.

Some additional things to perhaps consider:

• We should probably provide in what language the non-translated string was entered. So that iD can set the correct lang attribute for these.
• There might be cases where a regional preset applies to a multilingual region (Switzerland or Canada for example) or several regions with different languages. In this case it would be necessary to manually specify multiple translations in the preset JSON directly.

[tordans]

There might be cases where a regional preset applies to a multilingual region (Switzerland perhaps) or several regions with different languages. In this case it would be necessary to manually specify multiple translations in the preset JSON directly.

That would move us away from the Transifex based process quite a bit. If we came up with a way to keep just one translation workflow, that would be better IMO. Maybe there is a way to automatically add context to the translation (https://docs.transifex.com/localization-tips-workflows/the-complete-guide-to-adding-context-to-strings) that would tell the Translator that this is a regional preset that might be better kept as is.

[1ec5]

This tool already generates some YAML comments that Transifex treats as context. So my suggestion was to generate more YAML comments based on additional JSON properties.

In general, I think even regional presets should be translatable. After all, as an iD translator for Vietnamese, I already have to translate hundreds of community-index descriptions of YouthMappers chapters in countries that have no Vietnamese-speaking mappers. I don’t mind the ability to translate regional preset names where it makes sense to – you can find language speakers in the most surprising places sometimes – but translators should know that they aren’t obligated to spend much time on them. (Certain languages are quite accepting of loanwords from certain other languages. Others, not so much.)

I guess I’m not wedded to a particular solution here, but it would be nice to make more extensive use of that context feature. The build script could simply generate a comment saying which region(s) a preset is limited to.

[tordans]

@1ec5 FYI I paired with @tyrasd on https://github.com/ideditor/schema-builder/pull/93/files today to find a solution for this issue.