Closing the Loop: Feedback in Translation

From Ott09 Wiki
Jump to: navigation, search

Closing the loop -

  • Dwayne doesn't know what he's talking about.
  • How do we include translators as an integral component of the translation ecosystem, perhaps thinking of them as a part of a translation “loop”?
    • Example on – discussions emerge around specific issues, which can then be tracked and learned from.
  • Backing up – is there a “meta-language” which can be used to codify different aspects of the translation process and then is subject to machine-parsing and can inform development.
  • In “closing the loop,” are we just talking about the translator/developer loop, or are we also including the wider translation ecoystem. I.e., reduce the duplicative effort.
  • What kinds of feedback would we like/expect?
  • Localizers can examine the code itself.
  • There is a step where the internationalization people do a QA (quality assurance) review (aka pre-translation) which tends to catch errors.
  • Translation brief schema – it's a sort of description of the specific translation needs for the document (at a meta-level), which can then be used for third parties to objectively review the extent to which the translation itself meets those needs, and if not, why not.

Can this facilitate translator-to-translator exchange? Annotations and other methods of clarifying the “bits” of the translation process can make this happen.

  • An interesting problem – How do you convey to people when something is not worth localizing? Some technical documentation, for example, is really not worth translating since the materials of interest are not available in the target language.
  • Case study in translation: Imagine a translator encountering a particular turn of phrase in the original language and being savvy to its unique meaning... how can that person convey this information to subsequent translators? How much annotation is needed so that future translators will be able to capitalize on the knowledge? Is it just an awareness-building issue (I.e., there might be an issue here...) or is it a solutions process (I.e., there is a problem, and here is the specific solution...).
  • Annotating the annotations (including deletion and the capacity to filter) is also important.
  • Rohan's view (as a localizer):
    • Placement of the sentences in the translated text – sometimes the order must be changed in order to preserve meaning.
    • UI is often anathema to the form of the new language, but it is rare that there are “UI options” which can accommodate those differences.
  • Gisela's view (as a localizer):
    • Need previews of things to see whether they will work prior to publication.
    • We discussed some ways to make this feasible at various permission levels.
    • Temporary publishing locale.
    • “Code-checker”
    • Screenshots from autogenerated preview.
    • Etc
  • Question regarding the best UIs for facilitating translation – how many strings, what functionality, etc.?
  • Direct feedback from translators themselves seems pretty useful.

Key outcomes:

  • Annotations about the translation are crucial. Imprecise is better than missing.
    • Feedback to the original developers (of the resource and/or the translation platform).
    • Feedback to fellow translators.
    • Feedback to the translators themselves as they are translating – e.g., images, additional contextual info, functionality, etc.
  • We agreed that it is important for feedback to be encouraged and facilitated regardless – break the echo-chamber effect for programmers. We got great translator-to-programmer feedback just in this session.