Bug 419774 - Allow to export PDF content as xliff for translation then reimport it
Summary: Allow to export PDF content as xliff for translation then reimport it
Status: REPORTED
Alias: None
Product: okular
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Other Linux
: NOR wishlist
Target Milestone: ---
Assignee: Okular developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-04-07 01:18 UTC by Thiago Sueto
Modified: 2020-04-07 01:18 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thiago Sueto 2020-04-07 01:18:56 UTC
This is a very specific functionality only available in two proprietary, paid, Windows applications in the entire market as far as I know, InfixPDF and FlexiPDF. I can easily guess it's difficult to implement.
If Okular had this functionality and it worked well, it would be the go-to application for translators on Linux and possibly on Windows too.

The use case is fairly common for translators:
* The translator receives a PDF from a client
* The tool exports the PDF content (including information about its position) as XLIFF, a standardized file format used for professional translation with many translation tools
* The translator translates the XLIFF file
* The file is then reimported to the PDF
* The text is put into its original place in the PDF, even if a bit out of place
* The translator delivers the translated PDF to the client

This is more efficient than PDF > DOCX/ODT conversion which is also common in the translation industry, mostly because it usually does not render as many translation issues in CAT tools such as excessive tags, so the translation process itself is easier despite requiring PDF editing in the end.