Localisation

[cgbosse]

[cgbosse]

Do we need a translation? If so into which languages?

[josecelano]

Do we need a translation? If so into which languages?

Hi @cgbosse I suppose it makes sense to translate only the Tracker Index (not there Tracker). Adn that's a big effort. Maybe we should include it in a "feature request" discussion, defining what we want to translate.

Application messages

We can translate the application messages (static content generated by developers: error messages, labels, etcetera):

• Extract labels/messages to translation files or database.
• Add new translations once they are decoupled from the code.

Content generated by users (all roles)

Or we can allow the user to add translations for their contents: torrent title, description, categories, etcetera.

cc @da2ce7

[da2ce7]

Localisation of Torrust (and human facing aspects of all our projects) is a important project.
We should do it comprehensibly and intelligently.

This comes under the "Important and Low Priority" classification. – We should take our time to it well and do it only once.

---

I recommend the general policy of "empowering user and reduce data loss; automate everything else".

For example, users should be able tell their software about their regional and language preferences. I.e:

• I live in Germanic Europe
• My Primary Language(s): English (UK)
• My Secondary Language(s): English (Other)
• My Tertiary Language(s): German, Russian

Whenever information is provided by the user, the users language and regional information metadata should be saved alongside the input. – The user should also be empowered to be able to provide an additional localisational hints.

If I copy-paste this input: Αντιγράφω αυτό το κείμενο από ένα άλλο έγγραφο, I should be able to provide a meta-data hint along-side my default localisation metadata, that it is in-fact in Greek.

---

We should provide a best-effort, closest match when displaying information for the user.

The layout, number, date, time, etc, should be set based upon the users regional preference. The common interface should be set according to the users first primary language; but if not available, the next best.

Data presented should be displayed along-with it's localisational metadata: and automatically translated into the preferred language when outside the users preferences; users should be able choose to view the original also.

---

When users of multiple languages are collaborating on a single document, the document should have a single canonical version that is maintained: edits will update this canonical version in a single agreed language.

---

Translation notes, directives and, overrides should be available to enhance the automated transaction process; this information should be in a in-line referenced metadata format.

Overall: users tell the application about their regional and language preferences and the interface adapts to give the user the best localised experience. – Data provided should be remembered along side the context of the localised experience, with possibilities for the user to make classification.

[cgbosse]

From what I read this is something for the future, besides the person Mick spoke about has not contacted me so far.