I guess tnt should be able to use resource files as a source and be able to import translated strings from resource files and update the translated resource files.
User stories:
Continue to use resource based translations only, but use tnt for the management of the translations.
Use resources side-by-side with .tnt-content/ based translations.
Convert from resources to .tnt-content/ based translations.
Semantics:
Resources can be added as a source, like assemblies. For that, tnt add may be simplified so that it automatically detects a language, a language name, an assembly file, or a resource file.
When tnt extract is used, the strings are read from the resource file, and the translation files get updated similar to the tnt extract of an assembly. After that, all the resource files with matching translation languages are imported and the new strings are being set to needs-review (not final because we do want to show analytical warnings).
Every time a translation language is changed, all the resource based sources are loaded, and if the translated strings of the sources changed, they are exported to the language resource files.
Notes:
The context of the strings extracted from the resource files should probably be their ids.
When an original string changes in a resource file, the translations of the previous original string are set to unused and the resource based translations that existed before are imported and set to a state needs-review, which is what we want: the translations do not get lost, but a translator should take a look at it. Here it would be nice if we can run a machine translation again and help the translator. This seems to be a candidate for a new feature for tnt translate. For example, we could run a suggestion for each needs-review record that adds suggestions for the translators, or we could extend tnt export with an option to avoid polluting the model. tnt export --with-suggestions sounds nice.
A resource file supports multiple different ids with the same original string and distinct translated strings in the same language. How should tnt handle this case?
I guess
tnt
should be able to use resource files as a source and be able to import translated strings from resource files and update the translated resource files.User stories:
tnt
for the management of the translations..tnt-content/
based translations..tnt-content/
based translations.Semantics:
tnt add
may be simplified so that it automatically detects a language, a language name, an assembly file, or a resource file.tnt extract
is used, the strings are read from the resource file, and the translation files get updated similar to thetnt extract
of an assembly. After that, all the resource files with matching translation languages are imported and thenew
strings are being set toneeds-review
(notfinal
because we do want to show analytical warnings).Notes:
unused
and the resource based translations that existed before are imported and set to a stateneeds-review
, which is what we want: the translations do not get lost, but a translator should take a look at it. Here it would be nice if we can run a machine translation again and help the translator. This seems to be a candidate for a new feature fortnt translate
. For example, we could run a suggestion for eachneeds-review
record that adds suggestions for the translators, or we could extendtnt export
with an option to avoid polluting the model.tnt export --with-suggestions
sounds nice.