Problems with Lingo and Across Language Server

[Ina]

Has anyone here had experience with Lingo and Across Language Server? We're encountering issues importing translation bundles back into Lingo and would appreciate any help, in English or German.

Here's the specific issue:

When importing XLF files from Lingo into Across using the XLIFF file import template, it combines all sentences within a paragraph, jumbling the structure and resulting in errors upon re-importing the files to Lingo. Unfortunately, there seems to be no way to adjust the import template settings.

Furthermore, if the XLF files from Lingo are imported into Across using the XML file import template, while everything appears correct in Across, the source text gets overwritten by the target text. Consequently, when importing back into Lingo, both the target and source are displayed in the target language.

[Dafra08]

I have very limited experience with Across, and have never imported from Lingo. But could the first issue be some segmentation rule mishap rather than something with the import template? Check the segmentation rules in Across. Maybe it helps to create explicit segmentation rules in Lingo too, before exporting to XLF, although it sounds like the problem is on the Across side.

[ouarda]

Hi Ina,

Do you have an update on this issue?

On my part, I have similar issues and discussed it with support.
We figured the segmentation issue is due to not having <p> tags in the <li> tags of sublists.
E.g.,
<ul>
<li>this is the main list</li>
<ul> <li> this is a sublist</li></ul>
</ul>
Instead, it should be
<ul>
<li><p>this is the main list</p></li>
<ul> <li> <p>this is a sublist</p></li></ul>
</ul>

I believe this correction is the best practice for HTML 5.

[Psider]

Are you saying you were told li elements must contain a p element? If so I don't believe this is true based on the spec.
https://developer.mozilla.org/en-US/doc ... Element/li

https://html.spec.whatwg.org/multipage/ ... li-element

I couldn't comment on suggestions for specific translation services, however, simply that the spec doesn't require it as far as I can tel.

[JaredHess]

We've been using Across for some time with HTML content. We've now started switching over to Flare and Lingo from our previous authoring tools. I'm told by our localization management team that Across expects a single xlif file for project, but Flare/Lingo gives us one xlf per topic from Flare. Has anyone found a way of combining multiple xlf files together into a single file that Across can read and also a way of separating the xlf files back out into their original filename and folder location once localization through Across is done so that Lingo and Flare can process them? We just had a meeting on it today and sounds like we're considering creating our own in-house script to handle this, but if someone knows of an existing way to do this, I'd be interested.

[Ramon-L10n]

Hi there,

I wouldn't dare to contradict your localization management team but according to Ina's original post

importing XLF files from Lingo into Across

seems possible.

When it comes to translating MadCap Flare projects, there are multiple approaches to consider. Based on my experience, I’d like to suggest an alternative method that might streamline your workflow.

Currently, the process involves importing XLF files from Lingo into Across. While this method does the trick, it has its limitations so, since you already have experience in translating HTML files with Across, I would suggest you give it a go at translating Flare’s source files directly.

Translating Flare’s source files directly can save time and reduce complexity in the long run, especially if your project is frequently updated or new target languages are added.

This approach involves the initial overhead of filtering out the files required for your actual outputs and possibly converting some files to formats supported by the CAT tool to generate a translation kit. However, this investment will pay off later.

Consider the numerous interactions your suggested approach will involve:

Current Approach:

• Flare > Lingo > XLFs > Script > XLF > CAT > XLF > Script > XLFs > Lingo > Flare

Proposed Approach:

• Flare > Translation kit > CAT > Flare

While the initial setup might require some effort, the long-term benefits of a streamlined process will outweigh the initial overhead.

As a localization engineer, I’m always on the lookout for better ways to carry out my workflows and learn along the process. So, what are your thoughts on this approach? Have you decided on a method yet?

Ramon

PS: For some reason, my posts take several days to get cleared and published, so please don't judge me too harshly if my input is already outdated when it finally gets published.