Pages in topic:   [1 2] >
ProZ.com's l10n files don't open in Trados 2009
Thread poster: Samuel Murray

Samuel Murray  Identity Verified
Netherlands
Local time: 00:11
Member (2006)
English to Afrikaans
+ ...
Jul 6, 2010

G'day everyone

ProZ.com's own l10n files are in XLF format, like this: proz__countries_eng_to_afr.zip.

Swordfish and Virtaal open these files without any difficulty. Trados 2009 barfs an error message:



Any idea what I must do to ProZ.com's XLF file to hack it into acceptable shape for Trados 2009 to be happy?

Thanks




[Edited at 2010-07-06 18:57 GMT]


Direct link Reply with quote
 

Natalie  Identity Verified
Poland
Local time: 00:11
Member (2002)
English to Russian
+ ...

Moderator of this forum
Hi Samuel Jul 6, 2010

Please contact the developers. I had similar problems with the Russian files, and Mauricio helped me. The problems were with the files themselves.

Natalia


Direct link Reply with quote
 

Natalie  Identity Verified
Poland
Local time: 00:11
Member (2002)
English to Russian
+ ...

Moderator of this forum
BTW Jul 6, 2010

This posting belongs not to Trados forum, but to the Localization forum - would you mind if I would move it?
N.



[Edited at 2010-07-06 23:24 GMT]


Direct link Reply with quote
 

Samuel Murray  Identity Verified
Netherlands
Local time: 00:11
Member (2006)
English to Afrikaans
+ ...
TOPIC STARTER
This is a Trados problem, so... Jul 7, 2010

Natalie wrote:
This posting belongs not to Trados forum, but to the Localization forum - would you mind if I would move it?


The way I see it, it is a Trados problem, hence my posting it here. I tested the l10n files in two other programs and was able to open them (apparently successfully). Only Trados gives an error, so my first instinct is that the problem lies with Trados. If the Trados people think that the problem lies with ProZ.com's l10n files, they should say so, and why.


Direct link Reply with quote
 

Samuel Murray  Identity Verified
Netherlands
Local time: 00:11
Member (2006)
English to Afrikaans
+ ...
TOPIC STARTER
The developers... Jul 7, 2010

Natalie wrote:
Please contact the developers. I had similar problems with the Russian files, and Mauricio helped me. The problems were with the files themselves.


The Trados developers or the ProZ.com developers?


Direct link Reply with quote
 

Natalie  Identity Verified
Poland
Local time: 00:11
Member (2002)
English to Russian
+ ...

Moderator of this forum
ProZ.com developers, of course Jul 7, 2010

There are some minor mistakes in the files that other programs simply ignore but Trados is unable to overcome them.

Direct link Reply with quote
 

Samuel Murray  Identity Verified
Netherlands
Local time: 00:11
Member (2006)
English to Afrikaans
+ ...
TOPIC STARTER
Paul's comments Jul 7, 2010

Paul wrote me a private e-mail with some comments. I hope he doesn't mind me quoting him here in the public forum. I'm not a programmer, so perhaps I'm mistaken, and if so, then perhaps Paul or someone who knows about these things can tell me.

Paul Filkin wrote:
Used unsupported language abbreviations
Changed source-language="eng" target-language="afr" to source-language="en-US" target-language="af-ZA"


According to the XLIFF 1.1 standard (and also the XLIFF 1.2 standard) the source-language and target-value values should be according to RFC3066, point 2.2 (or for XLIFF 1.2 to RFC4646, point 2.2.1) that the three-letter codes of ISO 639-2 are permitted as primary subtags. Doesn't this mean that "eng" and "afr" as source-language, target-language and xml:lang values are valid in an XLIFF file?

Invalid date time value
Change date="2010-05-19 20:53:40" to date="2010-05-19T20:53:40Z"


According to the XLIFF 1.1 standard the date and time should be in ISO 8601 format, and the Z and T notation is the *recommended* syntax (but not required), and if I understand the ISO 8601 format correctly, the format ProZ.com uses would be valid too.

Type attribute not declared
Fixed by removing the undeclared attribute (you could also declare it but this was faster and wasn’t translatable content) - type="needs_update".
Stage attribute not declared
Fixed by removing the undeclared attribute (you could also declare it but this was faster and wasn’t translatable content) - stage="1".
Group attribute not declared
Fixed by removing the undeclared attribute (you could also declare it but this was faster and wasn’t translatable content) - group="text_site".


This appears to be a problem with ProZ.com's l10n files, yes (though not the way Paul describes it, unless I misunderstood Paul's comment).

As far as I can tell, the element can't have a type, stage and group attribute. So declaring them won't fix the problem -- they should simply not be there in the first place. I know that XLIFF is extensible so that one can add non-standard attributes, but these can only be added to certain elements, which does not include .

Still, if that is so, then Trados' error message is confusing, because it implies that the attributes would be valid if they are declared.

Required attribute Process Name is missing
Add process-name="test" before phase-name="_countries".


You're right... the process-name attribute is required for the phase element:
http://www.oasis-open.org/committees/xliff/documents/cs-xliff-core-1.1-20031031.htm#process-name



[Edited at 2010-07-07 11:56 GMT]


Direct link Reply with quote
 

Mauricio Zoch  Identity Verified
Argentina
Local time: 20:11
English to Turkish
+ ...
Thanks Jul 7, 2010

Hi Samuel,

Thanks for this information, i can work with this and remove all the non standard information to avoid any kind of problems with Trados.

I will let you know when it done so you can download again those files and work with Trados.

Best regards,
Mauricio


Samuel Murray wrote:

Paul wrote me a private e-mail with some comments. I hope he doesn't mind me quoting him here in the public forum. I'm not a programmer, so perhaps I'm mistaken, and if so, then perhaps Paul or someone who knows about these things can tell me.

Paul Filkin wrote:
Used unsupported language abbreviations
Changed source-language="eng" target-language="afr" to source-language="en-US" target-language="af-ZA"


According to the XLIFF 1.1 standard (and also the XLIFF 1.2 standard) the source-language and target-value values should be according to RFC3066, point 2.2 (or for XLIFF 1.2 to RFC4646, point 2.2.1) that the three-letter codes of ISO 639-2 are permitted as primary subtags. Doesn't this mean that "eng" and "afr" as source-language, target-language and xml:lang values are valid in an XLIFF file?

Invalid date time value
Change date="2010-05-19 20:53:40" to date="2010-05-19T20:53:40Z"


According to the XLIFF 1.1 standard the date and time should be in ISO 8601 format, and the Z and T notation is the *recommended* syntax (but not required), and if I understand the ISO 8601 format correctly, the format ProZ.com uses would be valid too.

Type attribute not declared
Fixed by removing the undeclared attribute (you could also declare it but this was faster and wasn’t translatable content) - type="needs_update".
Stage attribute not declared
Fixed by removing the undeclared attribute (you could also declare it but this was faster and wasn’t translatable content) - stage="1".
Group attribute not declared
Fixed by removing the undeclared attribute (you could also declare it but this was faster and wasn’t translatable content) - group="text_site".


This appears to be a problem with ProZ.com's l10n files, yes (though not the way Paul describes it, unless I misunderstood Paul's comment).

As far as I can tell, the element can't have a type, stage and group attribute. So declaring them won't fix the problem -- they should simply not be there in the first place. I know that XLIFF is extensible so that one can add non-standard attributes, but these can only be added to certain elements, which does not include .

Still, if that is so, then Trados' error message is confusing, because it implies that the attributes would be valid if they are declared.

Required attribute Process Name is missing
Add process-name="test" before phase-name="_countries".


You're right... the process-name attribute is required for the phase element:
http://www.oasis-open.org/committees/xliff/documents/cs-xliff-core-1.1-20031031.htm#process-name



[Edited at 2010-07-07 11:56 GMT]


Direct link Reply with quote
 

Mauricio Zoch  Identity Verified
Argentina
Local time: 20:11
English to Turkish
+ ...
Extension of the file Jul 7, 2010

Hi Samuel,

Im still working on it but meanwhile, you have any particular reason to change the extension file from xml to xlf? If you use the file with .xml (our files have this extension) instead of .xlf you will be able to work with Trados without any problems.
The problems is when Trados get a file with .xlf extension, looks like is more strict with the content of that kind of files.

Best regards,
Mauricio


Direct link Reply with quote
 

Samuel Murray  Identity Verified
Netherlands
Local time: 00:11
Member (2006)
English to Afrikaans
+ ...
TOPIC STARTER
I must have forgotten... Jul 7, 2010

Mauricio Zoch wrote:
You have any particular reason to change the extension file from xml to xlf?


Well, I did have a reason originally, but I think your question is whether I would have a problem keeping the extension "XML" when using Trados, and the answer is "no", I have no problem with that. I did not realise that a change in the file extension would make a difference (the file type is, after all, declared in the file itself anyway).

If you use the file with .xml (our files have this extension) instead of .xlf you will be able to work with Trados without any problems.


Thanks for the tip.

Samuel


Direct link Reply with quote
 

SDL Community  Identity Verified
United Kingdom
Local time: 00:11
English
Studio and ProZ XLF Jul 7, 2010

Hi Samuel,

I don't mind you posting this, but I think I need to add some clarification now. I didn't intend this as an invalidation against the standard, rather I wanted to show you how to work through the errors and be able to ensure your file could be processed by Studio.

There are many knowledgeable people reading this forum, far more knowledgeable on the standards than me, so I had a quick chat internally and would like to just add our understanding as follows.

Samuel Murray wrote:

According to the XLIFF 1.1 standard (and also the XLIFF 1.2 standard) the source-language and target-value values should be according to RFC3066, point 2.2 (or for XLIFF 1.2 to RFC4646, point 2.2.1) that the three-letter codes of ISO 639-2 are permitted as primary subtags. Doesn't this mean that "eng" and "afr" as source-language, target-language and xml:lang values are valid in an XLIFF file?


These are also valid under the specification, but we only support xx-XX format of languages as we follow the Microsoft Culture sets and always insist on a primary and subtag format. So the error here relates to being able to use this with Studio and not whether it complies with the spec. or not.

Samuel Murray wrote:
According to the XLIFF 1.1 standard the date and time should be in ISO 8601 format, and the Z and T notation is the *recommended* syntax (but not required), and if I understand the ISO 8601 format correctly, the format ProZ.com uses would be valid too.


Date – yes “Z” is optional but I think they missed the “T” as well. This is required to indicate the beginning of the time element.

Undeclared Attributes.

Samuel Murray wrote:
This appears to be a problem with ProZ.com's l10n files, yes (though not the way Paul describes it, unless I misunderstood Paul's comment).

As far as I can tell, the element can't have a type, stage and group attribute. So declaring them won't fix the problem -- they should simply not be there in the first place. I know that XLIFF is extensible so that one can add non-standard attributes, but these can only be added to certain elements, which does not include .

Still, if that is so, then Trados' error message is confusing, because it implies that the attributes would be valid if they are declared.


Not declared attributes – this is text which is returned from the XLIFF schema (that’s what we use for verification). We are using the XLIFF schema to validate the file and return a generic error that something is incorrect. In this case the attributes are undeclared, but you are right in that had you declared them it would have probably errored anyway as they would be undeclared against the schema. I was incorrect there. Removing them was the only thing needed.

On this basis it may be that most of these points failed a validation against the XLIFF 1.1 spec. It's important to have rules but it's all a little academic as long as you can process the file

Regards

Paul


Direct link Reply with quote
 

Samuel Murray  Identity Verified
Netherlands
Local time: 00:11
Member (2006)
English to Afrikaans
+ ...
TOPIC STARTER
@Paul Jul 7, 2010

SDL Support wrote:
I don't mind you posting this, but I think I need to add some clarification now.


Thanks, your comments make for interesting reading.

On this basis it may be that most of these points failed a validation against the XLIFF 1.1 spec. It's important to have rules but it's all a little academic as long as you can process the file


I share your attitude. I'm not a pedant when it comes to file format standards, but I do believe that users should have access to information like what we discussed above.

Basically, what was learnt here, is that Trados requires language codes in the format XX-XX and that it requires the date/time in the Z+T format. One might call this the Trados dialect of XLIFF It is also useful for developers of other tools or l10n systems to be aware of these dialectical issues if they want to make their tools and/or files compatible with Trados.

I would have thought that ProZ.com's files would work on Trados, at least (given the relationship between Trados and ProZ.com).


Direct link Reply with quote
 

Mauricio Zoch  Identity Verified
Argentina
Local time: 20:11
English to Turkish
+ ...
Trados support upgraded Jul 7, 2010

Samuel Murray wrote:

I would have thought that ProZ.com's files would work on Trados, at least (given the relationship between Trados and ProZ.com).



Hi Samuel,

Can you download the localization file again and try to use it on Trados? Notice that you have a new option at the moment of download a file on localization. You can choose download .xlf extension with a properly format to use on Trados now.

Please let me know if you have any problems using localization files again.

Best regards,
Mauricio


Direct link Reply with quote
 

SDL Community  Identity Verified
United Kingdom
Local time: 00:11
English
Thanks Mauricio Jul 7, 2010

Samuel Murray wrote:

I would have thought that ProZ.com's files would work on Trados, at least (given the relationship between Trados and ProZ.com).



I'll put the cheque in the post


Direct link Reply with quote
 

Samuel Murray  Identity Verified
Netherlands
Local time: 00:11
Member (2006)
English to Afrikaans
+ ...
TOPIC STARTER
Trados now opens the XLF files, thanks Jul 8, 2010

Mauricio Zoch wrote:
Can you download the localization file again and try to use it on Trados? Notice that you have a new option at the moment of download a file on localization. You can choose download .xlf extension with a properly format to use on Trados now.


Trados 2009 now opens the file (with an XLF extension) without any error messages. Theer is a warning about "en" versus "en-US", but that is only a warning and not an error message.

If I use the XML extension, Trados does not open the file correctly (or rather, it opens it correctly, but not in the way that a translator of XLF files might have wanted). When Trados 2009 opens the file with an XML extension, it offers all translatable content as "source text", including any existing target text segments. This is what one would expect for generic XML, but it does mean that one has to use the XLF extension if you want to translate ProZ.com's XLF files in Trados 2009.

As an aside, it would seem that Trados does not support string version numbers, which is *crucial* for the ProZ.com l10n file system. Neither Virtaal nor Swordfish supports it either. Perhaps these tools do support it but one has to activate it...? I wonder what tool ProZ.com's l10n team had in mind for translators to use, since the version numbers are the only way to distinguish untranslated strings from translated strings and to distinguish old translated strings from up-to-date translated strings.


Direct link Reply with quote
 
Pages in topic:   [1 2] >


To report site rules violations or get help, contact a site moderator:


You can also contact site staff by submitting a support request »

ProZ.com's l10n files don't open in Trados 2009

Advanced search







Déjà Vu X3
Try it, Love it

Find out why Déjà Vu is today the most flexible, customizable and user-friendly tool on the market. See the brand new features in action: *Completely redesigned user interface *Live Preview *Inline spell checking *Inline

More info »
Wordfast Pro
Translation Memory Software for Any Platform

Exclusive discount for ProZ.com users! Save over 13% when purchasing Wordfast Pro through ProZ.com. Wordfast is the world's #1 provider of platform-independent Translation Memory software. Consistently ranked the most user-friendly and highest value

More info »



Forums
  • All of ProZ.com
  • Term search
  • Jobs
  • Forums
  • Multiple search