Display screenshots to translators

[gkovacs]

I've developed a system for providing a screenshot to translators to illustrate the context in which a message is used in the program, and wanted to help integrate it into Transifex if there was any interest in such a feature. Basically, the way it would work is, the developer can upload some screenshots in addition to the message template file, and they would automatically be matched to messages, so that when the translator is translating a message, a screenshot will be shown. If interested in the details, I've published a paper on it in CHI 2012 ( http://groups.csail.mit.edu/uid/other-pubs/chi2012-screenshots-for-translation-context.pdf )

In terms of code, the prototype implementation I used for the paper, which works with gettext message files, is MIT-licensed, and is written in Java, is at https://github.com/gkovacs/textmatch . I realize Java isn't very popular in the FOSS world, so I can clean it up and rewrite it into C and write documentation if needed. I was primarily interested if there was any interest in integrating such a feature into Transifex, and if yes, how I could help do so.

[glezos]

Geza, this is pretty cool. We were discussing this approach but never
actually proceeded in implementing it.

One important element to note is that besides desktop apps, there are
a number of web and mobile ones. Given that these often have richer
formatting and positioning (eg. CSS), it'd be interesting to see
results for these platforms as well.

Now, the best way to integrate this would be to ask a developer to
upload a zip with all his screenshots. Then Tx would run the pattern
matching in the background, store the associations between Source
Entities and images in the DB and present them in the web editor.

[gkovacs]

Glezos, glad to hear there's interest! I agree with the mode of integration, that's basically how my system already works. For web/mobile apps with complex formatting, I can probably test out its matching accuracy in a few weeks (currently a bit busy with final projects), but just re-training the OCR system is probably going to fix most of these types of issues.

I was primarily just wondering if there was sufficient interest in adding such functionality to Transifex (wouldn't want to work on it several months only to have the work rejected), and what kind of work I'd need to do (ie, do I need to rewrite my codebase in another language, or is Java acceptable; would I need to do the Transifex integration myself or would it be sufficient to just have a simple matching API).

That said, as this would end up being a fairly large change, do you think it would it be better to move this discussion to transifex-devel?

[mpessas]

Yes, it would be better to move this to the transifex-devel google group.
It would be great to know how this works and see, how easy it would be to integrate it with Transifex.