OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [dita] Product names and reuse: a very serious anti-pattern when translating documents


Title: Email signature standard
If I were to create a variables architecture now, I'd deliver the XML to Translation with resolved variables in XLIFF, which is already a translation standard for many companies. Translators wouldn't see the variables, only the text in context, thus the issue is a non-issue.

There are considerations other than translation and reuse for using variables as I've indicated prior that is a ROI scenario, too. (Such as late-changing product and feature names or customer-driven overrides.)

That companies should train their writers to use XML element effectively is a given. That people can do bad things in documentation is nothing new and nothing peculiar to XML. I've had to deal with training issues at every XML implementation I've every been involved in.

I don't see any viable argument here that would negate the benefits of using variables effectively, when used effectively, in XML with or without translations.

Every product I've ever worked on without variables for products and feature names has been an expensive, time consuming, repetitive nightmare of late product and feature name changes searching sometimes through tens of thousands of topics trying to find the changes in question that could easily have been solved with an intelligent variables architecture and a little writer training.

Troy

On 1/21/2013 5:14 AM, Andrzej Zydron wrote:
Hi Kristen,

Your recommendations are very sound and such restricted use should allow for successful substitution. The underlying problem though remains: if you provide a mechanism people will inevitably misuse it to their own detriment. I would certainly have issue with Troy's suggestions which indicate grammatical use of substitutions within sentences.


Best Regards,


Andrzej Zydroń

---------------------------------------

CTO

XTM International Ltd.

PO Box 2167, Gerrards Cross, SL9 8XF, UK

email: azydron@xtm-intl.com              

Tel: +44 (0) 1753 480 479

Mob: +44 (0) 7966 477 181

skype: Zydron

www.xtm-intl.com

 

Description: Description:
                  cid:image002.png@01CCE7FF.2711B390

 

 

 

On 20/01/2013 23:16, Kristen James Eberlein wrote:
Additional recommendations that I neglected to include:
  • Ideally the product name should be trademarked and not translated into the target language
  • Avoid using adjectives with the product name
Best,
Kris

Kristen James Eberlein
Principal consultant, Eberlein Consulting
Co-chair, OASIS DITA Technical Committee
Charter member, OASIS DITA Adoption Committee
www.eberleinconsulting.com
+1 919 682-2290; kriseberlein (skype)

On 1/20/2013 6:02 PM, Kristen James Eberlein wrote:
Andrzej, thanks for your very full  post. You clearly took the time to craft an e-mail to the list that covered thoughtfully the many issues involved here.

I don't know to what extent people try to implement reuse at the less-than-sentence level. I can tell you what I currently recommend when people want to go down this path ...
  • Implement reuse only for those very specific items that are very costly if incorrect -- or costly to change, such as product names or operating systems or prerequisites. For example, "Acme Widget," "Microsoft Windows XP," "Java SDK, version 6.0"
  • Ideally, use those reused items only in standalone form, for example, a list item that only contains the phrase "Microsoft Windows XP"
  • If you must use a reused term in a sentence, use it only in the singular form and in the nominative case, for example, "Acme Widget is a ..."

Any comments on the cost aspects of this approach? It does require substantial writer education and awareness ...

Best,
Kris

Kristen James Eberlein
Principal consultant, Eberlein Consulting
Co-chair, OASIS DITA Technical Committee
Charter member, OASIS DITA Adoption Committee
www.eberleinconsulting.com
+1 919 682-2290; kriseberlein (skype)

On 1/20/2013 4:47 PM, Andrzej Zydron wrote:
Hi Troy, Mark and Kristen,

Thank you for your questions, replies and comments, and apologies for my tardiness in replying: I have been very busy last week.

The short answer is:

1. Coping with noun inflection changes will add between 10% to 20% to your translation  costs.
2. You cannot escape the adjectival agreement trap which will produce ungrammatical output in most languages.

The cost of translating into one language will cost roughly the same as writing the original. If you translate into the typical 21 to 40 languages then the increase in cost will be substantial. You are creating a rod for your own back.

The long answer:

What is suggested is a very serious anti-pattern. As I laid out in my previous post, what is proposed works reasonably well in English and possibly a few other languages, like Mandarin, that have a primitive morphology. These languages are unfortunately atypical. Languages with a primitive morphology belong predominantly to a category of language termed creole: they are formed by a fusion of two or more languages. The English we use today was formed during the 15th century by a fusion of medieval French and old English. The impact of French on the English that we use today should not be understated - it was immense.

The vast majority of human languages have a rich, or in the case of Slavonic languages an extremely rich morphology. English nouns do not have gender association and their morphology is only expressed in the possessive and plural forms. An obvious consequence of this is that word order in sentences is of paramount importance, which is not true of morphologically rich languages.

Let us now move on to the substantial flaw that is caused by treating product names, or any other noun, as a variable when it comes to translation: the noun inflection and the adjectival agreement trap.

1. Noun inflection
The only inflections for nouns in English is the possessive and plural forms. Other languages can have many more forms depending on the role that the noun is playing in the sentence. Take my mother tongue, Polish. There are 7 noun cases in Polish: nominative, genitive, dative, accusative, instrumental, locative and vocative, each with a possible different ending. It is very difficult for monolingual English speakers to grasp the fact that nouns can have so many different forms. Why is this a problem for automatic noun substitution? The answer is a great deal: 7 does not go into 2 (English nominative and possessive). Let is look at a practical example in the following  sentence where the noun 'spanner' in Polish is 'klucz':

English:
Please undo the bolt using a spanner.

Polish:
Proszę odkręcić śrubę kluczem.

Please note the inflection of the noun in Polish as it takes on its instrumental form, which results in adding en 'em' ending. You can redo the translation so that spanner uses the nominative form:

Używając klucz, proszę odkręcić śrubę.

The English equivalent is:
Using a spanner please undo the bolt.

This imposes an extra burden on the translator which you will have to pay for. The translator has to rearrange the sentence: this is an extra task and will increase the cost of translation. It can also result in a very strange style for the document as a whole.

2. Adjectival agreement
Nouns in English do not express gender. This is quite unique. Most other languages associate a particular gender with each noun and require that any adjective accompanying a noun has to agree in terms of both gender and in most instances also with regard to case. Let us take a simple example of automotive product names from Ford of Europe: Fiesta, Mondeo and Focus. Let us also take the example of Polish, which is typical of all Slavonic languages. Nouns in Polish can have three genders: masculine, feminine and neuter.

Fiesta in Polish is automatically assigned feminine gender because it ends with an 'a'. Mondeo is automatically associated with neuter as it ends in an 'o'. Focus is masculine, mainly because in ends in neither 'a' nor 'o'. Now let us look at the simple noun phrase 'new model':

a) Nowa Fiesta
b) Nowe Mondeo
c) Nowy Focus

Please note that all three models force different endings on the adjective 'new'. Add to this the fact that the adjective will also have to take on the inflection of the noun we have the following examples:

English:
Driving the new 'model' is a great experience:

Polish:
a) Jazda nową Fiestę jest wspaniałym przeżyciem.
b) Jazda nowym Mondeo jest wspaniałym przeżyciem.
c) Jazda nowym Focus'em jest wspaniałym przeżyciem.

As you can see, even if we forced the use of the nominative case for the model name, which may result in a stilted translation, we cannot escape the gender trap. You will end up with ungrammatical text, which depending on your target audience may not be the result you desired.

The examples given above were obviously for a single target language, but Polish is fairly typical of most morphologically rich languages. Other languages have different traits, such a Finnish which has 15 inflections for nouns, no gender but requires adjectival agreement. French has an even more primitive noun morphology than English, but has a very strong gender requirement on adjectives and particles, e.g. nouveau, nouvelle, du, de la, le, la. Hebrew also requires adjectival agreement for gender and has three cases for nouns as does unsurprisingly Arabic.

To sum up it is ill advised to use any mechanism to provide for individual word or noun phrase substitution if you are going to translate your output to any other language with a richer morphology than English, unless you are prepared for the extra cost and possible low quality of the resultant output. Human language is too rich and varied to be treated in simple word substitution terms.

Email signature standard

Best Regards,


Andrzej Zydroń

---------------------------------------

CTO

XTM International Ltd.

PO Box 2167, Gerrards Cross, SL9 8XF, UK

email: azydron@xtm-intl.com              

Tel: +44 (0) 1753 480 479

Mob: +44 (0) 7966 477 181

skype: Zydron

www.xtm-intl.com

 

Description: Description:
                        cid:image002.png@01CCE7FF.2711B390

 

 

 

On 18/01/2013 17:20, Troy Klukewich wrote:
Hi Kristen:

At the former company, we attempted to restrict product names as untranslated, and this initially worked for western languages where we started first, but then it didn't work later for some eastern languages that already had a special trademark for that country, from what I remember. I think we had some problems too around feature names that in some cases simply had to be translated even for cultural reasons.

We had Information Developer training around how to use product and feature name variables effectively by restricting the way we wrote around them to avoid translation common issues.

Finally, we avoided references to the product in general going forward. Fortunately, in software, we can often refer generically to the product as "the system" or application in context. Still, we had some high level material that required the product name and we would use the variable there.

In most cases, we used the majority of variables for nasty, constantly changing feature names. :-)

In another case, we had a specialized product that required variables for business object names that could be overridden by the customer, which we then output to in-place help variables with a dynamic mapping file. (Kind of cool, actually, though little seen elsewhere.)

In short, I don't think there is an easy answer that avoids changes to schemas, workflow, writing practices, and output processing for holding and processing an effective product or feature element along the lines of a variable, but once implemented, the automation and customization is very powerful.

I have played around with content references with some success to simulate variables as used in a previous company. I forget what the specific limitations are, but I wasn't totally happy with it.

If I were to create a variables architecture for DITA today using OT as a reference processor, I would create a generic schema for variables, then specialize attributes as needed for products and features (at minimum). Use a mapping file in XML to hold the resolved values and keys. Then create a processing plug-in for those variables, which might include special graphics associated with the product name, if needed (has actually happened).

Troy

On 1/16/2013 9:03 AM, Kristen James Eberlein wrote:

Troy, there were a couple of questions that I want to ask. Did the company's style guide restrict the content developers as to how they used the product names, for example, using product names only in the nominative case?

Were the product names translated or left in English? I think translated, based on your post, but wanted to check -- some companies handle the problem of reusing company names by NOT translating them.

You mentioned using attributes to indicate plurals or possessives; did you do anything to handle case or part of speech?

Thanks for your interesting post!

Best,
Kris

Kristen James Eberlein
Principal consultant, Eberlein Consulting
Co-chair, OASIS DITA Technical Committee
Charter member, OASIS DITA Adoption Committee
www.eberleinconsulting.com
+1 919 682-2290; kriseberlein (skype)

On 1/16/2013 8:47 AM, Troy Klukewich wrote:
Hi Andrzej:

We translated the English XML content and mapping files into multiple languages, including Chinese, Japanese, and Arabic, which are probably some of the more difficult languages to translate. The agencies worked with our build kit and generated translated versions per language, including PDF. Granted, we had some great development resources to program the XSLT and XSL:FO appropriately to handle multiple languages.

I do remember some iterations where translation had to tweak the PDF output until we programmed a solution (indexing was challenging for Japanese, right-to-left languages, etc.). In any case, the amount of total manual work translation had to perform versus previous iterations was massively reduced with subsequent cost savings and rapid turn-around. From what I recall, we reached 100% automation for all languages handled.

If you could be more specific about which language morphologies cannot work with variables, I'd be interested. In some cases, the best solution might be to dump out an XLIFF with resolved values for variables, so the base XML isn't translated, but the XLIFF version of the same with a two-way transformation back to the build kit for a translated version of deliverables.

Some translation groups will work with build kits, some don't, so this also needs to be factored into workflow.

So I suspect that there may be no perfect global solution to handle all possible languages from base DITA XML, but a technical solution that handles most and then an alternate workflow for those languages that cannot work with variables as such.

Troy

On 1/15/2013 1:34 PM, Andrzej Zydron wrote:
Hi Troy,

Thank you for this interesting post. Your mechanism will work for English, and the small group of languages with a similar primitive morphology. Unfortunately it will fall apart when you come to translate the XML content into any language with a richer morphology - the resultant output will produce ungrammatical output and the cost of recovery from this will be extensive.

English is a linguistic freak (
a fact that is lost on most monolingual English speakers) which allows for the relative easy substitutions that you described. I you plan to translate your content into other languages this is not a practical possibility.

Email signature standard

Best Regards,


Andrzej Zydroń

---------------------------------------

CTO

XTM International Ltd.

PO Box 2167, Gerrards Cross, SL9 8XF, UK

email: azydron@xtm-intl.com              

Tel: +44 (0) 1753 480 479

Mob: +44 (0) 7966 477 181

skype: Zydron

www.xtm-intl.com

 

Description: Description:
                                  cid:image002.png@01CCE7FF.2711B390

 

 

 












[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]