Implement gettext translation file generation

[jrb0001]

This PR allows selecting gettext as an alternative to the CSV format in the translation settings.

It also fixes the following issues:

• Glossary can show wrong entry if the name of one entry is used as a translation of another entry.
• "Collect translations" added non-dialogic translations in various situations.
• "Collect translations" didn't remove translations that did no longer exist on the filesystem.
• "Remove translations" didn't delete timeline translations created with the PER_TIMELINE + NEXT_TO_TIMELINE combination.
• All characters used the same translation keys.
• Order of characters/glossaries/timelines within a file (Per Type mode) was unstable.
  • This is solved by sorting based on source path. Or would you prefer sorting by translation id or something else?

Things I noticed while testing:

• Choice nodes have a disabled_text translation, even if the choice has no condition. Wouldn't it be better to only add it if it is actually used?
• The "Default locale" and "Testing locale" dropdowns only allow languages, not locales. It makes sense not to show every single locale by default, but why is it filtering the locales collected from translation files too?

[CakeVR]

Thank you for your PR.
I will review this in the following days.

I want to quickly talk about the Glossary. I have not looked at the code, so this is only a quick exchange of information.

The Glossary, unlike Timeline Text Events, does not fall back and that is intended by design. If there is no translation for the target locale, they won't do anything. This ensures no wrong Glossary is displayed between languages.

Let me know if this is what you encountered.

[jrb0001]

Not sure what I did different this time, it works on the old version.

Available translations of the timelines: en, it
Available translations of the glossaries: en, de

Testing locale: en

• Old: timeline: en, glossary: en
• New: timeline: en, glossary: en

Testing locale: it

• Old: timeline: it, glossary: en
• New: timeline: it, glossary: en

Testing locale: de

• Old: timeline: en, glossary: de
• New: timeline: en, glossary: de

Testing locale: fr

• Old: timeline: en, glossary: en
• New: timeline: en, glossary: en

So the behavior is still the same and it always used the fallback logic of godot.

There is still one issue in the old version and fixed in this PR:

• Use the original locale name of one glossary entry in a translation of another glossary entry.
• Run the game with the original locale.
• The text box highlights the correct words.
• The tooltip shows the wrong entry.

[jrb0001]

Bypassing the fallback logic of godot completely would be possible, but the new code would still need some sort of fallback. Otherwise the game would need to have the glossary in every single language+country+variant+... combination a player could have.

I am not sure if the large complexity of building our own fallback logic is really worth it. The only situation where it makes a difference is if timelines, but not glossary, are translated for a specific locale. And it would also be extremely difficult to test it because locales have so many corner cases.

[jrb0001]

I also made changes to some events to reduce the number of unused translation entries:

• The choice event no longer creates an unused translation entry for disabled_text if the choice can't be disabled.
  • It is still possible to use the fallback behavior in the main language but a different text in other languages. I am not sure how helpful this really is.
  • Alternative: Remove all empty disabled_text entries even if the choice can be disabled.
    • If a game doesn't use different disabled texts, this could reduce the number of entries even more.
    • This would also allow a generic implementation across all event types, if we want that.
• The label event no longer creates a translation entry for display_name if it is empty.
  • Or is there any situation where you would need a display name in some languages, but not in the main language?

Please let me know if you want to keep the old behavior or prefer something different.

[LucaVazz]

Hey there 💭

It would be awesome to get this merged - this would enable me and my team to have unified translation handling, as we prefer to use gettext for the translation of our godot scenes and scripts.

I've rebased the branch onto the current state of main:
https://github.com/LucaVazz/dialogic/commits/jrb0001-gettext-rebased/
Mainly just UID fixes where needed.

I've tested the rebased branch using https://github.com/dialogic-godot/test-project and from my view it works flawlessly 🎉

@jrb0001 While rebasing I dropped 9f71491 as on main the func DialogicTimelineFormatSaver._save got refactored to instead use DialogicTimeline.as_text
Inside DialogicTimeline.process the fields event.source_path and event.source_line_number already get set.
Is that sufficient or should these fields also be set inside DialogicTimeline.as_text?

Regarding the glossary #2356 (comment), from my perspective the current state is fine - it follows the same fallback logic of Godot in scenes and scripts when using gettext translations so I'd say the behavior is expected and acceptable.

[jrb0001]

@jrb0001 While rebasing I dropped 9f71491 as on main the func DialogicTimelineFormatSaver._save got refactored to instead use DialogicTimeline.as_text
Inside DialogicTimeline.process the fields event.source_path and event.source_line_number already get set.
Is that sufficient or should these fields also be set inside DialogicTimeline.as_text?

I wrote this PR 11 months ago so I am not sure anymore about the exact reason. Maybe it was to fix the line numbers when a timeline with newly added or reodered events get saved?