ayacoo / xliff Goto Github PK

Currently only CSV is supported. The formats xlsx and json would also be good.

When generating, only the original language should be considered. Currently, the translations are also translated again.

When using the translate command and a file already exists, it is adjusted and in this process, already existing translations are overriden. See here:

Cannot autowire service "Ayacoo\Xliff\Service\Export\CsvExportService": argument "$extensionName" of method "__construct()" is type-hinted "string", you should configure its value explicitly.

Files with a comment are not yet processed cleanly

• Interface and factory for export service
• PSR-14 event to register custom export

Add logging when API call errors occur

https://aws.amazon.com/de/translate/

The translation from EN to DE was not well possible. Some of the code was hard-coded.

In old XML/Xliff files it can happen that resname is not yet set. Then the ID should be used.

Add a file option for migration command

https://github.com/ayacoo/xliff/blob/main/Classes/Command/ExportCommand.php#L74

When translating to EN, there must be a mapping to EN-GB

deepl returns capitalised isocodes from the API. The user should not care whether they are upper or lower case, so the translate command must be optimised.

To be able to support more translation services later, the current deeplService must be extracted.

• Add fallback in DeeplService
• Add hint for db action in README.md

At the moment, a CSV is generated for each file during export. For translation agencies, a complete file makes more sense.

When translating, the HTML is not transformed cleanly. Originally planned for the & sign, another solution must be found.

<trans-unit id="key">
    <source><![CDATA[Small desktops (≥992px &lt; 1200px)]]></source>
</trans-unit>

becomes

      <trans-unit id="key" resname="key">
        <source><![CDATA[Small desktops (≥992px &amp;lt; 1200px)]]></source>
      </trans-unit>