Description of problem: As translator it would be nice to be able to choose the source language when translating. Version-Release number of selected component (if applicable): 3.0.0-alpha2-SNAPSHOT How reproducible: Always Steps to Reproduce: 1. Choose to translate to a language 2. Look at the left side of the view. Actual results: You are ready to translate from "default" language Expected results: You are ready to translate from "default" language, but can as well change the "from language" to a better suited language for just you. Most desirable is that you choose the source language in the header of the view in some kind of drop-down menu. When doing so it updates all source text fields (on the left side) to the currently desired source language. Additional info: This is a feature request, I guess it is usefull for all projects that is well spread, and have more and better translators that translates from there neighboring languages than from the default language (usually english).
Okay, so this is about letting translators choose one of the existing translations as the source language (indirect rather than direct translation).
If I understand the RFE correctly, Translator 1 has translated from language A to language B, now Translator 2 wants to translate from language B to language C. I'm a bit concerned that it could turn into a game of https://en.wikipedia.org/wiki/Telephone_(game) I think it might be safest if this feature were turned off by default, but the system administrator could enable it for all projects if desired, and perhaps project maintainers could have the option of turning it on for individual projects. Other thoughts: In the case of software translation, the original source text may contain comments, which are meant to guide the translation with extra information about the context. Unless Translator 1 has translated the comment (how will this translated comment be stored in the database, and where will it appear in the UI?), Translator 2 may product an incorrect translation. The editor currently propagates new/modified translations to everyone viewing the workspace within a second or two. What will happen in Translator 2's editor if translations for language B are updated? Will Translator 2 be prevented from beginning translation if language B is less than 100% translated, or if the translations haven't been reviewed yet?
(In reply to Sean Flanigan from comment #3) > If I understand the RFE correctly, Translator 1 has translated from language > A to language B, now Translator 2 wants to translate from language B to > language C. I'm a bit concerned that it could turn into a game of > https://en.wikipedia.org/wiki/Telephone_(game) > > I think it might be safest if this feature were turned off by default, but > the system administrator could enable it for all projects if desired, and > perhaps project maintainers could have the option of turning it on for > individual projects. > > > Other thoughts: > > In the case of software translation, the original source text may contain > comments, which are meant to guide the translation with extra information > about the context. Unless Translator 1 has translated the comment (how will > this translated comment be stored in the database, and where will it appear > in the UI?), Translator 2 may product an incorrect translation. > > The editor currently propagates new/modified translations to everyone > viewing the workspace within a second or two. What will happen in > Translator 2's editor if translations for language B are updated? > > Will Translator 2 be prevented from beginning translation if language B is > less than 100% translated, or if the translations haven't been reviewed yet? I understand your concern but I am thinking of this option only as a reference for the translator. When the translator selects a language he sees the phrases beneath the source phrases. He will always see the source language for each phrase as usual. If there is no translation from source to the selected language for a phrase the translator is, simply, not given any reference. When it comes to updating, wouldn't work to update the reference phrases in the same manner as usual, that is, when another translator changes the translation the reference phrase also changes?
(In reply to Hannes from comment #4) > I understand your concern but I am thinking of this option only as a > reference for the translator. When the translator selects a language he sees > the phrases beneath the source phrases. He will always see the source > language for each phrase as usual. If there is no translation from source to > the selected language for a phrase the translator is, simply, not given any > reference. Okay, that sounds better. > When it comes to updating, wouldn't work to update the reference phrases in > the same manner as usual, that is, when another translator changes the > translation the reference phrase also changes? It would, but thinking in terms of the current implementation, changes to language B translations are currently broadcast using TransUnitUpdatedEvents on the GWTEventService channel ("Domain") for a workspace. A workspace represents a combination of a project, a version and a language: thus language B and language C have separate channels. When Translator 3 selects the option to show language B as well as A, this means the editor will need to subscribe to the extra channel for language B's workspace. These channels can be pretty busy, and subscribing to two would use twice the I/O. I have been thinking that we need to make the channels narrower, and I think this feature will make it more urgent - instead of a channel for project+version+language, perhaps we need channels for individual document+language. We also use these workspace channels to keep the stats bars up to date (the summary up the top, and also the document stats bars in the Documents list). If we stop sending TransUnitUpdatedEvents on the workspace channel, we may need to send some sort of StatsUpdateEvent instead, and have the stats bar listen for it. With those changes in place, the editor should be much less bandwidth-intensive, and it would be affordable to subscribe to events from multiple languages for the current document.
Pull request: https://github.com/zanata/zanata-server/pull/126
Seems to work, but with bugs. Verified at 1eda383c84d22d89a4cdf69496f5914d70834f4b Bug 1035095 - Reference translation feature truncates the text Bug 1035100 - Reference translation feature does not give any indication to the state of the source Bug 1035103 - Reference translation feature not real-time