Leaving myself here so I will remember to add option for robotidy to autotranslate tokens. And it would be interesting to add support for polish. Although I don't have idea how to translate some of the keywords such as [Teardown] (probably not [Zburzyć] :D). Maybe to avoid problems with not accurate translations it would be good idea to let people vote on certain translations? Or use https://crowdin.com .

Yeah, coming up with good translations for some of these terms is going to be hard. No idea what Teardown could be in Finnish either. A major problem related to this is that changing terms would be backwards incompatible. Perhaps we should support English always so that hard-to-translate terms could be initially skipped.

Great Idea.

We decided to move this one and highly related non-English Given/When/Then support (#519) to RF 5.1. That wasn't done because we don't consider these issues important, on the contrary, but simply because RF 5.0 already contains lot of great new features and we want to get it out as soon as possible. These translation related issues will be the highest priority issues in RF 5.1 and the plan is to start its development right after RF 5.0 has been released.

We need to do some technical choices before proceeding with the implementation.
The goals here are:

• offer simple way for users to provide translations
• use a file format which can be parsed easily with the Python standard library
• introduce no performance penalty

Since this is mostly a lookup problem (does a given string, say *** testitapaukset ***, represent a valid token), some kind of configuration file is most likely appropriate. A full-blown translation framework like gettext might be too complicated.

In addition, it needs to be decided whether we support multiple forms for some tokens. For example, currently the table headers allow both singular and plural English form (test case and test cases). For the sake of simplicity and clarity, it might be better to allow just one form in the translations.

Based on all the above, some options for the configuration file format are:

• INI files
• JSON
• YAML
• TOML

Of these, INI files and JSON are the ones having parsers in the Python standard library.
JSON is quite unwieldy to edit by hand and it does not support comments, and additionally no benefit is gained by it's support for a wider range of data types than INI files.

I would really like to also results be considered. How does log.html look like
and could we allow to some extent results automatic translations.

@yanne one thing I would also think are the existing standards and work beyond Python standard libs.
JSON is pretty much used in projects like i18next and all over the content of internet (like in headless cms).
It might actually result in best tooling for content creation for the translations.

Translating log and report is important but it would most likely be better to update their underlying tech first. We are planning to do such tech update with Libdoc already in RF 5.1 (#4304) and if that goes well then log/report could be next.

Regarding technical choices:

What about the python gettext API, it comes with python and is a well established standard, editing and handling PO files is easy and there are several tools wich helps you to write your translations.

Yeah, coming up with good translations for some of these terms is going to be hard. No idea what Teardown could be in Finnish either. A major problem related to this is that changing terms would be backwards incompatible. Perhaps we should support English always so that hard-to-translate terms could be initially skipped.

This supporting English forever would solve (or work-around) the problem of deciding what to translate and what to leave in English. I rather wish RF not to enforce using translations even if they are available---then everyone can decide whether e.g. whether they will write RETURN in English or in their language. (This is Robocop what I probably wish to (optionally) check whether a translation was used wherever possible.)

gettext is an option later but an overkill now. We just need to match strings during parsing.

The plan is to support English as an alternative automatically. In the future we may make that configurable if there are needs. Notice also that at least in the beginning we don't plan to support translating control structures like RETURN or IF. Support for that can be added later.

📢 This comment lists everything that can be translated in RF 5.1.

Markers to translate, covered by this issue, are just headers and settings. With headers we support both singular and plural formats in English and we can support them also with other languages. For test related headers and settings we have task related aliases.

Other translations in RF 5.1 are Given/When/Then prefixes used in behavior-driven development (BDD) which is coveted by issue #519. With these prefixes it is probably a good idea to look at what translations Cucumber uses.

Headers:

• Settings, Setting
• Variables, Variable
• Test Cases, Test Case
• Tasks, Task
• Keywords, Keyword

Settings in the Settings section:

• Documentation
• Metadata
• Suite Setup
• Suite Teardown
• Test Setup
• Test Teardown
• Test Template
• Test Timeout
• Task Setup
• Task Teardown
• Task Template
• Task Timeout
• Test Tags (New in RF 5.1, see New Test Tags setting as an alias for Force Tags #4368)
• Keyword Tags (New in RF 5.1, see Support adding tags for all keywords using Keyword Tags setting #4373)
• Library
• Resource
• Variable

Settings for tests/tasks:

• Documentation
• Tags
• Setup
• Teardown
• Template
• Timeout

Settings for keywords:

• Documentation
• Arguments
• Teardown
• Timeout
• Tags
• Return (Deprecated and won't support translations)

BDD prefixes (#519)

• Given
• When
• Then
• And
• But

We obviously need help from the community with translations. We have decided to use the #localization channel on our Slack as the main collaboration forum and separate channels can be created for each language there as well. If you are interested to help but haven't yet joined out Slack community, you can get an invite here.

If anyone wants to join in on the translation of RF please submit your translation here https://robotframework.crowdin.com/robot-framework

Current translation status:

This zip file contains:

• Portugese by @HelioGuilherme66
• Portugese Brazil by @HelioGuilherme66
• Dutch
  LANG.zip

I added initial translations for Finnish for testing and demonstration purposes in bfec5a5. Everything that was needed is the new Fi class in the languages module. The same approach obviously works also with other languages.

I would prefer languages to be added via pull requests by their respective authors to have contact info for them automatically stored. It's fine to leave some of the terms untranslated, the English terms will nevertheless work. You many also decide not to translate [Return] because it will be deprecated and removed in the somewhat near future anyway.

Notice that the class in the languages module will be the name of the language to use from the command line. Matching name is case-insensitive so, for example, the aforementioned Fi class can be used like --language fi.

Language variants such as Brazilian Portuguese could have a class name like PtBr and be used like --language ptbr. If the usage would be more convenient like pt-br or pt_br, we can ignore - and/or _ when matching. Alternatively we could make it possible for each class to provide a custom name to be used with them. Do you @HelioGuilherme66 have a preference?

I would suggest we use and stick to whatever the commonly accepted syntax for describing languages is. I think is the ISO standard - ISO 639-1 and then the additional macrolanguages. I would stick to the hyphen and be strict in interpreting it.

Better use the hyphen then. The following should be accepted: pt (this is the preferable, nice to have a lookup for regional LANG code page, and switch to it, otherwise, default would be pt-pt), pt-pt and pt-br.
There may be more regional variants, like for example, Angola.
(I haven't looked at code, but maybe a specific Robot Framework language environment variable could exist):

No --language option ==> Lookup ROBOT_LANG ==> English (en) If None else ROBOT_LANG

With --language pt ==> Lookup ROBOT_LANG ==> pt-pt If None else ROBOT_LANG (user would need --language en to bypass ROBOT_LANG)

With --language pt-pt ==> no lookup for ROBOT_LANG ==> pt-pt

With --language pt-br ==> no lookup for ROBOT_LANG ==> pt-br

With --language fi ==> no lookup for ROBOT_LANG ==> fi (applicable for all languages with no regional variants)

I don't think we need an environment variable to control the language. We already support ROBOT_OPTS and giving it a value like --language pt has the same effect as the proposed ROBOT_LANG with value pt. I'd also rather think about adding support for config files than add more environment variables. I'm not entirely against the idea, though, so you can submit a separate issue to discuss it further.

I don't want to make handling language codes too complicated at least in RF 5.1. For example, I don't want to do any extra lookups if someone uses pt and not pt-pt. We just need to decide which one to use or make it so that both mean the same thing.

The hyphen in pt-br is easiest to handle so that we simply ignore it when matching the given language code to the available ones. Then the class name can be just PtBr and matching it works. Alternatively we could require the class name to be Pt_Br in this case or require the class to have an attribute telling the language code to use. I don't think these have any concrete benefits over simply ignoring the hyphen in matching. That obviously means that ptbr works in addition to pt-br, but I don't think that really matters.

Big thanks for @leeuwe for setting up Crowdin to have a place where the community can work together with translations. Thanks also to everyone who has already participated in translation efforts.

If you want to test translations created at Crowdin, you need to download the language file (seems to be named Core.yml) and convert it to Python that Robot Framework understands. I have created a script that can do conversion automatically. Just download the script and run it like this:

python crowdin.py Core.yml lang.py

The generated Python code can be used directly with Robot Framework like robot --language lang.py tests.robot. The generated class can also be added to Robot's languages module via a pull request to get it included as a built-in language.

The support for localized markers ought to be done now. We still need to add actual translations and document all this, but that's covered by #4390.

@d-biehl helped making the public robot.api.Languages API used by external tools like editor plugins better. See #4494 for details.