to support translation allow the export of all translations

Many tools like poedit can use a translation memory - with this TM you can translate much faster and the tool makes suggestions.

A po file can be converted to the format TMX and this is the format for tools like OmegaT or Virtaal.

This is also a helper as long as we don't have a formal dictionary support.

Since i expect this feater easy to realize and a high impact for translators (more consistency, higer efficiency, better usage of the existing tools) I set the Priority to critical.

Comments

gábor hojtsy’s picture

Status: Active » Closed (duplicate)

The only reason to not allow this currently is the question of server resource consumption. A fully exported language .po can be 20MB as we estimated in Paris. Now imagine people exporting 20MB files on the fly all the time.

I concur it would be very useful for several reasons, including support for desktop translation memories, maintaining internal translation servers for projects, etc.

The issue at #596466: Make export work with any filter combination is very similar and aims at the automated translation features of desktop tools as well. Basically, ideally you could export the whole stuff or filter down your export with different ways, even cross-project for certain keywords if you want to. The backend implementation would be the same for both issues, so I think we should mark this as duplicate.

gábor hojtsy’s picture

BTW additionally to exporting all data, implementing a translation memory on the server side would also be ideal. To refresh/update your translation memory, you'd need to export the whole language probably too often. Especially if even more people get on the translation memory bandwagon :)

So ideally, we could set up a 3rd party memory on the server side, and interface with that for suggestions if you ask for them on translation. I've submitted #740494: Find translation memory to integrate with and implement integration for this and marking one similar issue as duplicate for that as well.

ahwebd’s picture

gábor hojtsy’s picture

Priority: Critical » Normal
Status: Closed (duplicate) » Active

Yes, in fact I'd love to refactor the l10n_packager code to allow for the current per-release packaging as well as overall packaging for projects and even generate a dump of all projects per language. That would be useful for translation server syncing maybe and for translation memory and Thomas points out. Let's keep this active in itself.