We would like to use the XLIFF format as base for translating certain texts from German into French and Italian. (The translations will be performed with SDL Trados.)
From the specification, there seems to be precisely one target language per XLIFF file, but additionally there can be specified further "alternate languages". Specifying two target languages would therefore be possible from the spec:
<xliff xmlns="urn:oasis:names:tc:xliff:document:1.2" version="1.2">
<file source-language="de" target-language="it">
<body>
<trans-unit id="hi">
<source>Betrieb</source>
<target>Divisione</target>
<alt-trans>
<target xml:lang="fr">Site</target>
</alt-trans>
</trans-unit>
</body>
</file>
</xliff>
Is this using XLIFF in the expected sense? Or would it be better to produce two documents, one with target language fr and another one with target language it? (I don't like the repetition)
<alt-trans> is not intended for having <target>s in more than one language in each trans-unit; it's rather intended for translation match be it translation memory, machine translation matches, or simple an outdated target string which needs to be updated according to most recent changes in the source string. Having said that, in some cases <alt-trans> is perceived as a workaround for translating what the industry calls "adaptive languages" (French for Canada is often adapted from French translation) without having separate files. As a localization practitioner who has to deal with Xliffs from various sources and presented in various schemas, I recommend to avoid this hack. It is more common and accepted to use the <file> tag to embed trans-units for multiple languages in one Xliff file:
<?xml version="1.0" encoding="utf-8" ?>
<xliff version="1.1" xml:lang='en'>
<file source-language='en' target-language='de' datatype="plaintext" original="Sample.po">
...
<body>
<trans-unit id="1" restype="button" resname="IDC_TITLE">
<source>Title</source>
</trans-unit>
<trans-unit id="2" restype="label" resname="IDC_STATIC">
<source>&Path:</source>
</trans-unit>
...
</file>
<file source-language='en' target-language='fr' datatype="plaintext" original="Sample.po">
<trans-unit id="1" restype="button" resname="IDC_TITLE">
...
</body>
</file>
</xliff>
I work for a translation agency.
I have not seen multilingual xliff files yet. So to make your and your agency's life easier, I would build individual files.
Also other tools like e.g. CenShare create individual files.
And it makes it easier to hand it over to different translators.
According to the OASIS wiki:
An XLIFF document is normally a bilingual file. It has one source language (the language of the original extracted file), and one target language.
However, the <alt-trans> elements can be in language other than the source or target one.
Source: How many languages can I put in an XLIFF document?
Related
I have a GSchema defining some flags like so:
<flags id="org.example.program">
<value nick="ENGLISH_WORD" value="1"/>
<value nick="ANOTHER_WORD" value="2"/>
</flags>
However I have been informed by a translator that these are not processed by gettext or offered in the .pot file. Is there a way I can mark these as translatable?
The default values can be translated but the translations are substituted from .mo files at runtime. You have to put the textdomain in the attribute "gettext-domain" of the "<schemalist>" resp. "<schema>" element. You also have to put the locale category into the attribute "category" of the "<default>" element. Read the paragraph "Description" in https://developer.gnome.org/gio/stable/GSettings.html for more information.
I recommend that you examine the sources of a recent Gtk application and see how the different components are localized. GNU gettext has recently been improved to offer better support for localizing desktop applications and therefore the process is currently evolving. In particular, you usually no longer need intltool.
When I export my XLIFF file from Xcode, none of the strings I declared with NSLocalizedString have a < target> element. The strings generated from my storyboard do have a < target> element. Has anyone seen this before? Google reveals nothing.
String:
let oops = NSLocalizedString("Oops!", comment: "Alert box header")
Resulting XLIFF:
<trans-unit id="Oops!">
<source>Oops!</source>
<note>Alert box header</note>
</trans-unit>
I don't know specifically about XCode's behavior, but <target> is optional, so this is legal (although possibly inconvenient) XLIFF. (source: xliff 1.2)
You should be able to create add a <target> element during translation without problem, and most translation environments that support XLIFF should be able to do this as well.
The are a lot of useful tools that you can use to automatically write the target. Check on the App Store looking for xliff... some of these tools are also free.
As example, XLiffy seems to be easy enough to use.
I am converting DITA to XLIFF. In my technical solution I have to specialize (modify) xliff-core-1.2-strict.xsd to accommodate few DITA attributes. It means some attributes will go along with "g" tag. For Example:
<g id="00001" newAtt="this is new attribute" xid="009"/>
From the translation side I am not sure how it will work, so my questions:
Is it general practice that LSPs will get different flavor of XLIFF XSDs from different companies?
And is it possible for them to use it in their XLIFF editor by updating updated XLIFF XSD? I tried to explore “Transolution” but did not find any place where to place modified XSD.
Please let me know if you have any thought on this.
Thanks.
Here are my answers to your two questions:
I work for an LSP and I've seen all sorts and flavors of Xliff. Most of them try to stick to OASIS 1.2 transitional schema. Some of TMS/CAT producers added their own extensions. These producers normally provide an XSD so you can validate their Xliffs by adding that XSD to OASIS schema; e.g. SDL extensions to 1.2. When I'm customizing Xliff for a client, I normally do namespaces and provide a simple additional XSD; e.g.:
<trans-unit id="0" translate="yes" resname="msg_foo">
<superduper:uri>http://foo.bar/iJKLM9</superduper:uri>
<source>This is supposed to be a <superduper:g id="00001" newAtt="this is new attribute" xid="009"/> example.</source>
<target state="new"></target>
</trans-unit>
Most of the TMS/CAT tools are very basic (and closed) when it comes to their Xliff filters (or any of their filters for that matter) and I'm sorta kinda sure that they ignore your customized XSD.
Transolution is a very nice tool and my favorite Open Source translation tool. Unfortunately it's been long abandoned and has plenty of defects and shortcomings.
Anyway, if you provide a sample file, I can tell you what happens to non-conforming tags when it's imported into one of common, major CAT tools.
One final note; <g> seems to be retired in Xliff 2.0.
Forget about Transolution for one thing. I would try it with Trados, MemoQ or MemSource. Those are some of the big tools used in the translation business.
Personally I never got an XLIFF with a XSD, nor do I think Trados can handle it.
What do you need to change in the XLIFF?
I'm using the JSON localization plugin to add some string resource files to my xamarin.android project. Is there support for the MvxLang attribute in non-layout files such as searchable.xml and menu.xml files?
For example, I'd like to replace the below #string references with MvxLang attributes:
<?xml version="1.0" encoding="utf-8" ?>
<searchable xmlns:android="http://schemas.android.com/apk/res/android"
android:label="#string/ApplicationName"
android:hint="#string/SearchHint"
android:searchButtonText="#string/SearchHint">
</searchable>
Thanks
Mark
No. There's no built-in support for either of these.
For menu items, I'm sure you could add tokens to them fairly easily and then replace those tokens with strings when you load/inflate these files. Or alternatively you could even construct the menus in code.
For searchable I think the problem may be more difficult - I'm not sure that Android gives you much access to the searchable file or data object - I think the system uses them at a package level. I suspect for those few searchable text strings, you may have to use the built-in Android i18n system.
I'm trying to use xmltask for ant to modify a file in a subdirectory:
project/path/to/file.xml
The file refers to a DTD like this:
<!DOCTYPE data SYSTEM "mydtd.dtd">
I don't have the flexibility to change these documents.
This DTD is stored in the same subdirectory, which has always worked fine:
project/path/to/mydtd.dtd
Unfortunately, xmltask is trying to locate the dtd in my project's top-level directory, which is where my build file is located, and where I run from:
[xmltask] java.io.FileNotFoundException: /home/me/project/mydtd.dtd (The system cannot find the file specified)
I see in the xmltask documentation that I can correct this with an xmlcatalog element to tell it where to look up the file. But I need to use a dtd element, and I can only find examples for this element, not documentation; the examples show only a publicId, and if I understand XML correctly this document does not have one. I shouldn't need to specify this, anyway, right, since my document already says my DTD is stored locally and shows right where it is?
Why isn't xmltask finding the DTD correctly? What's the best way to correct or work around this situation?
An XML Catalog is the way to go here, it just needs a bit more perseverance.
As you correctly pointed out, the standard Ant <XmlCatalog> type only allows you to specify public DTD references when using the inline syntax, which is of no use to you. However, <XmlCatalog> also lets you specify a standard OASIS-syntax catalog, which is far richer, including resolving SYSTEM DTD references.
An OASIS catalog (full spec here) looks like this:
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog">
<system systemId="mydtd.dtd" uri="project/path/to/mydtd.dtd"/>
</catalog>
You can then reference this catalog from the <XmlCatalog>:
<xmlcatalog refid="commonDTDs"/>
<catalogpath>
<pathelement location="path/to/oasis.catalog"/>
</catalogpath>
</xmlcatalog>
And that's that. It's a good idea to build up a reusable OASIS catalog file, and refer to it from various XML-related Ant tasks, all of which can use <XmlCatalog>.
As an alternative, it looks like I can skip the whole validation by creating a blank file with the same name as the DVD file, and then deleting the file when I am done. Odds are I am going to go that route instead of using the catalog.
xmltask isn't finding it because it is looking in the current working directory. Ant allows you to specify a base directory using the basedir attribute of the <target> element. So I suggest you try this:
<target basedir="path/to" ...>
<xmltask...
</target>
It strikes me that it is not the XML/DTD that you really have the problem with, but getting xmltask to interact with the two of them as you want.
If that fails, you could use the Ant Copy task to copy the XML and DTD to the root folder before processing with xmltask, then copying back again.
Have you tried:
<!DOCTYPE data SYSTEM "./path/to/mydtd.dtd">
? Or an absolute path?
Also, you can find <dtd> description here.
I had a similar problem where an XML file had a doctype with SYSTEM reference that could not be changed.
<!DOCTYPE opencms SYSTEM "http://www.opencms.org/dtd/6.0/opencms-modules.dtd">
I first went down the road and created a catalog file with the OASIS catalog as described above, but to be able to use external catalogs I had to include the Apache Commons Resolver 1.1 (resolver.jar) in the Ant classpath (see http://ant.apache.org/manual/Types/xmlcatalog.html).
Because I had multiple machines on which this build was supposed to run this seemed overkill, especially since xmltask worked fine if I just removed the doctype definition. I wasn't allowed to remove it permanently because the doctype was needed elsewhere.
Ultimately I used this workaround: I commented out the doctype definition using Ant's replace task, ran the xmltask, and then put the doctype back into the file.
<replace file="myxmlfile.xml">
<replacetoken><!DOCTYPE opencms SYSTEM "http://www.opencms.org/dtd/6.0/opencms-modules.dtd"></replacetoken>
<replacevalue><!-- !DOCTYPE opencms SYSTEM "http://www.opencms.org/dtd/6.0/opencms-modules.dtd" --></replacevalue>
</replace>
<xmltask .../>
<replace file="${local.opencms.webapp.webinf}/config/opencms-modules.xml">
<replacetoken><!-- !DOCTYPE opencms SYSTEM "http://www.opencms.org/dtd/6.0/opencms-modules.dtd" --></replacetoken>
<replacevalue><!DOCTYPE opencms SYSTEM "http://www.opencms.org/dtd/6.0/opencms-modules.dtd"></replacevalue>
</replace>