[MGNLCTS-77] Detect translation files formats automatically when importing Created: 11/Jan/16  Updated: 05/Feb/16  Resolved: 02/Feb/16

Status: Closed
Project: Content Translation Support
Component/s: None
Affects Version/s: 2.1.1
Fix Version/s: 2.1.3

Type: Improvement Priority: Major
Reporter: Federico Grilli Assignee: Evzen Fochr
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0d
Time Spent: 1d 3h 55m
Original Estimate: Not Specified

Attachments: PNG File error-importing-xliff.png    
Issue Links:
Git Code Review
opened during git code review in MGNLCTS-75 Areas with Dialogs defined do not exp... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Release notes required:
Yes
Date of First Response:
Sprint: Kromeriz 29
Story Points: 3

 Description   

For instance, importing an XLF file may cause an exception due to the file imported not being in the expected format. To reproduce

  • On demoauthor.magnolia-cms.com create a new page /travel/test with a standard template
  • Add a textImage component to the main area and fill in with a title and a text
  • Export as XLIFF
  • Go to an online service http://xliff.brightec.co.uk/ and translate the file, then save the translation
  • Reimport the XLIFF file just created
  • An ArrayIndexOutOfBoundsException is thrown (see also screenshot). Nothing appears in the logs.

    The error seems happens when

  • importing an XLIFF file not zipped.
    • Here our app could do some validation and check whether the file is in the accepted format
  • importing an XLIFF file zipped but whose name does not reflect the locale code of the translation to be imported (e.g. de)
    • we could see if our import action could become more lenient in such a case, since the target language information is available in XLIFF file itself.

Finally we could possibly avoid asking users to choose an import format when the latter can be inferred from the uploaded file



 Comments   
Comment by Federico Grilli [ 11/Jan/16 ]

Issue was found during the pre-integration QA of the linked ticket but it precedes its implementation

Comment by Evzen Fochr [ 26/Jan/16 ]

To: "Finally we could possibly avoid asking users to choose an import format when the latter can be inferred from the uploaded file"

I think we should ask user to choose import format (choose importer to use). Right now we have 3 defined importers and its easy to differ between them by using file extension. But customer can have his own importer f.e. zipped batch of csv and than it easily breaks our recognition algorithm, because we use zip for xliff right now.

Comment by Evzen Fochr [ 27/Jan/16 ]

I was thinking more about it and creating follow-up ticket for removing choose of import format with suggestion how it can work.

Comment by Evzen Fochr [ 29/Jan/16 ]

To release notes.
1. It is possible to import zipped file for all provided importers. Unzipping will be done automatically.
2. Xliff importer implementation was changed to UnzippedXliffTranslationBundleUpdateReader and now only parse xlf file. Old XliffTranslationBundleUpdateReader class is deprecated.
3. Importer for file is chosen automatically by comparing extension property set for importer and file extension.

Generated at Mon Feb 12 00:32:59 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.