Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[jstead]

Hi there,

We are in the process of localising our website in a few languages through our internal translation team that use Trados to manage their translation projects. We have managed to import the XLIFF export into Trados without difficulties, however, the CDATA is breaking out content per sections of the website as opposed to sentences, which is the usual way for translation tools. This also means that the HTML tags and code are considered as translatable content and therefore not protected during translation.

We are wondering if there would be a way to modify the way the CDATA is working, i.e. instead of enclosing a whole section, it could enclose only text in between html tags.

This is an example of how it is looking now:
<source><![CDATA[<p>Joomla! is all about allowing you to create a site that matches your vision. The possibilities are limitless; this sample site will just get you started.</p>
<p>There are a few things you should know to get you started.</p>]]></source>

This is the way we would like to see it (if possible):
<source><p><![CDATA[Joomla! is all about allowing you to create a site that matches your vision. The possibilities are limitless; this sample site will just get you started. ]]></p>
<p>><![CDATA[There are a few things you should know to get you started. ]]></p></source>

Would functionality like this be possible through modifications, or is there a lot more in it?

Kind Regards,
Jason

[Harald Leithner]

I think thats not the way to go, IIRC <![CDATA is only valid once per entry and as the first characters.

But IIRC XLIFF has another way to support such things, the exporter could define segments that should not be translated.

On the other hand, this should be done by the translate program, it should understand html and rtf if not I'm not sure if I can help you very quickly cause by the lack of time.

[jstead]

Thanks Harald for the quick feedback, we did a few test with the translation tool and found we are able to break the content where we needed too. Yet to import the translations back in, but looks to be working great.

[Harald Leithner]

please provide feedback how it is working with xliff because I have very little experience with this technology.

[jstead]

Hi Harald, I sent you an email with results from some Xliff testing we did, but just realised it wasn't a PM. Did you receive this, or should I resend it through the PM channel?

[Harald Leithner]

Yes I got your mail but didn't have the time to answer, but you didn't describe a real problem or?
The only thing I see is that the target-tag is not created by your software and so jdiction has nothing to import... is this common by such software?

[jstead]

Yes, the problem was not having the <target> tag as its should be there from the initial export. The translation software doesn't add any structural content/tags to xliff/xml files, they are designed to only interact with the content needing translation.

By nature, a CAT(Computer-Assisted Translation) tool is creating an exact copy of the file that is fed into the system into another language. That means that these tools do not change the structure of the file, neither would they add tags that were not originally in the file. They purely extract the text that needs to be translated and through the process of translation, replace this text by the same text in another language.

Therefore, for the import to be working, we would need a target tag to be added to the export. That way we can tell the tool to ignore the source tag (we create a rule that tells the CAT tools that this text must not be translated) and only translate the target tag. We will end up with a file containing both the English and the translation, e.g:

Export file:
<source><![CDATA[This is some text to translate.]]></source> (will be hidden for translation in CAT tool)
<target><![CDATA[This is some text to translate.]]> </target> (will be translated by CAT tool)

Import file:
<source><![CDATA[This is some text to translate.]]></source>
<target><![CDATA[Ceci est le texte à traduire.]]></target>

We're happy to talk/provide any other information that may assist.

[Harald Leithner]

could you please try the attached version?

[jstead]

Hi Harald,

Sorry for the delayed response, we ran into a few problems in the process, but after a bit of testing, they all ended up being on our side and not jdiction.

The new Xliff structure is great, and imported into the CAT tool with no issues.

To have the CAT tool exports import back into Jdiction, we just had to convert the translated .xlf to UTF without BOM (as the CAT Tool exported it as ANSI) and find and replace state='needs-translation' to state='translated' which only takes a few seconds. So very quick process!


We are now looking to do a complete site export/translate/import as a final test and I just had an issue with exporting the following tables.
When exporting the below from jdiction, the xliffs are empty.
com_content -> articles
com_menus -> item
(empty as in just have the xliff tag)
<xliff version='1.2' xmlns='urn:oasis:names:tc:xliff:document:1.2'></xliff>

Is com_menus -> item the actual menus front end structure for each of my menus?

The other 2 tables I required are k2 -> item and modules -> module which both are exporting/re-importing with no issues.

Thank you very much again for the great support.

[Harald Leithner]

funny 6 year no new version of xliff and now we have 2.0 ;-) http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.html maybe I will support this in the future

Maybe your CAT tool doesn't support the features of xliff 1.2? Or I miss understood the specifications.

I added bom detection for xliff files, could you post the output xml of the CAT tool?

state='needs-translation' is interesting because the state after translation should be one of "final signed-off translated"...

[jstead]

Hi Harald,

The items you mention below (encoding format and translation state) are working great as far as Jdiction is concerned. I was just mentioning our process as an FYI in case it was helpful.

Our translation manager mentions that our CAT tool supports XLIFF 1.2, however she did not use the standard XLIFF filter provided by the CAT tool as it didn’t allow her to customise the content as she wanted. Instead, she used an xml filter to parse and tag the HTML content within the XLIFF file, so it was not part of the translatable content. (I have attached a copy of a single item exported from our CAT program).


The only outstanding issue we have at the moment, is trying to export the com_content -> articles and com_menus -> item tables from our site for translation, as they are currently exporting empty. Is there something specific that could be causing this?

Thanks Again,
Jason

[Harald Leithner]

So I have a new experimental version for you, the export has bin fixed.

But there is more, new written jdlanguageswitcher helper, support for aliases for urls and some other fixes.

please try carefully.

[Harald Leithner]

Thats a better version with an important bugfix.

[Harald Leithner]

Did you tried this version? And could you please give me some feedback, I need it?

[jstead]

Hi Harald,

Sorry for the delay, We have had multiple public holidays here and the office was closed.

Our translation manager is away until Monday 28th, so I am unable to test the import/export process with the CAT tool, but I have installed the new version, exported all tables and manually copy/pasted translations into the Xliff to test what I can.

It looks like all remaining tables (menus-items and content-article) now export correctly.

I was able to re-import the translated k2-items, modules-module and content-articles tables with no issues.

But, the menus-item table worked for every item except for 1 sub menu (and its various sub-sub menus). By not working though, they appear as translated (green flag icon and green border on entry field), but  blank. Found that I had to export the Xliff WITH duplicates, as the re-import only imported the 1st instance of each duplicate menu (each of our 6 products has the same submenu (features/benefits etc)

I also noticed that the Alias wasn't exported/translated for any menu items, not sure if this was planned to be in export, or to be manually added through Joomla UI. Although manually changing product alias to Produits for instance caused a 404. (I had this working earlier but cant remember how)

Please advise any other tests you would like me to try, or if there is any other information you may need. I will also do some more testing once the translation manager is in and supply feedback on this.

Thanks,
Jason