Request: Cascading Translations

Bug #57925 reported by Martin Meredith
14
Affects Status Importance Assigned to Milestone
Launchpad itself
Triaged
Low
Unassigned

Bug Description

for derivative languages (such as en_GB) it'd would be nice to be able to say, select an "upstream" language (in this case en_US) and be able to just say "no changes to this translation", so that if something hasnt changed, it's just a check box to say that instead of having to re-type out the same text

Changed in rosetta:
importance: Untriaged → Wishlist
Revision history for this message
Sridhar Dhanapalan (sridhar) wrote :

This should be implemented in a manner that forces translators to think about each string they are translating before they determine that no changes are required. The danger of making this too easy is that more subtle elements of translation like grammar and style may be ignored.

Changed in rosetta:
status: Unconfirmed → Confirmed
Revision history for this message
Sridhar Dhanapalan (sridhar) wrote :

This functionality would be of tremendous help to those translating into a different dialect of the same language, allowing free software to be closer to the people using it. The number of people who would potentially benefit from this are probably in the billions. No major world language is immune from dialecticism, so this affects the likes of English, French, Spanish, Portuguese, German and Chinese. Many smaller languages are affected by dialecticism as well. In short, it is a major problem.

To take an example, it would be far more efficient for Brazilian Portuguese translators to base their efforts on the main Portuguese translation (or vice versa). In the current environment, the two groups must independently create their own translations from C (which is usually en_US).

To cite another example, there are a number of independently-managed English translations. the English Translation initiative (https://wiki.ubuntu.com/EnglishTranslation) is an attempt to bring them all together to create one high-quality English translation (based primarily on en_GB). Once the support arrives in Rosetta, it will be able to easily form the basis of numerous dialect translations.

As things stand, translations groups are forced to re-invent the wheel many times over. There is no mechanism for them to co-operate and share their work. This is a major impediment and disincentive for translations in free software.

Rosetta has been tremendously successful at lowering the bar for non-technical people to participate in free software translations. I feel that simplifying the process dialecticism is the best means of lowering that bar even further to allow grass-roots participation.

Revision history for this message
Almufadado (almufadado) wrote :

If I am understanding this right ...
When translating to a language that has different dialect (ie.: pt_pt and pt_br) one TRICK is :

- add both languages to you preferred languages.
- add any other languages you feel comfortable with to be used as a reference

When opening the project for translation choose, for example
 translating into Portuguese (from Portugal)

translating <untranslated items > using <Brazilian Portuguese>

This either gives you a reference translation, saves you typing and also enables you to check the other dialect's translation correctness.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Related blueprints

Remote bug watches

Bug watches keep track of this bug in other bug trackers.