Translation keys containing a newline (\n) aren't translated when using the tr() function

[Nubilous]

Godot version:
3.3 RC 8

OS/device including version:
Windows 10

Issue description:
If the translation key you give to the tr() function contains one or more newline (\n) characters, the function will return the key itself instead of the translated version, even if the key is present in the translation file.

Something to note is that if you plug the key in a standard Label (without calling the tr() function), the translation does work as expected.

Steps to reproduce:

1. Create a translation.csv with just a column for 'key' and 'en'
2. Add a line to the csv file, with key This is a test string\nwith a newline and translation This is a test string\nwith a newline (translated)
3. From anywhere, call print(tr("This is a test string\nwith a newline"))
4. In the console, the untranslated key will be printed

Minimal reproduction project:
The project contains 3 test cases: printing to console, setting the string in a normal Label, setting the string in the bb_code field of a RichTextLabel. Only the Label version works as expected.
godot-translation-bug.zip

[Calinou]

When using CSV as a translation format, you should use translation keys rather than plain English as source strings. If you want to use plain English as source strings, use gettext instead since it's designed for that purpose.

Anyway, I can confirm this on 3.2.3 on Linux:

And 3.3rc8:

[Nubilous]

Thanks!

Is there a specific reason for CSV not allowing not being suitable for using the original text as key (outside of this issues, haha)? It's been pretty standard to use CSV/original text as keys on all professional projects I've worked on in the past (since it's very convenient in a text heavy game, and the tooling for it is ubiquitous, while the tooling for gettext, especially on Windows, is... lacking 😄)

As an aside, it seems odd that it would be a CSV issue, since it does work for Labels? I don't know enough Godot internals to judge that though 🙂

[Calinou]

Is there a specific reason for CSV not allowing not being suitable for using the original text as key (outside of this issues, haha)?

It's not that it's not allowed, it's that CSV isn't designed for this. Also, using "neutral" translation keys has other advantages, such as being able to distinguish the same text being used in different contexts, or being able to spot untranslated strings quickly.

while the tooling for gettext, especially on Windows, is... lacking

A Windows release of the gettext tools is linked in the documentation. Also, in a team project of a significant size, it's often better to use a translation platform such as Transifex or Weblate since it prevents people from stepping on each other's toes when working on the same translation.

[Nubilous]

(This is not meant as a counter-argument, just wanted to add my experience/considerations when doing game dev that needs localization. For reference, I've worked on three multi-year commercial game projects with 4-10 people that were localized)

After the first project, we chose to use 'non-neutral' keys for translations mostly because 'neutral' keys can make files and UIs hard to read, especially stuff like definition files with lots of text entries. This increases iteration time for content designers. Same goes for the gettext tools: as far as I can tell, there is no way to auto-add new keys when you add new text in Godot, which means all content designers would need to learn a new commandline tool, which is less than ideal 😄 (that's why I mentioned the StringKeys addon for Godot, which is a godsend, but only works with CSV)

Obviously, in an ideal world you'd write a tool that makes creating content in that environment easier, but especially in small teams you can't always afford that. Using the original string as key is a cheap way around that.

I only have experience with commercial game projects where we hired an external translation team. They all did their own data processing and had their own toolsets, so the format we gave them never mattered.

In any case, I've found a workaround that works for us atm. I'll look into gettext some more for our next project. 🙂 I hope the CSV side gets some love, since it's almost there, and it's probably good to give teams to option of using it if their tool chain is better suited to it 😄

[akien-mga]

There are two issues here:

• tr("String with\nnewline") pass in a script will expand the newline and will not match a "String with\nnewline" key. That's why the print fails, and it would also fail when overriding the text property of the Label.
• RichTextLabel doesn't seem to do auto-translation at all. So the text needs to be set from scripting with tr(), which suffers from the first issue.