I'm looking for folks who've first hand experience having
documents translated into foreign languages. Said documents
to include diagrams (think: callouts, legends), #included
text, etc.

I've a fair bit of experience with I18N/L10N for software
but the extent of the effort, there, is usually fairly limited.
And, there's less of a need for a cohesive approach as the
interactions are "punctuated" (no pun intended).

Recommendations for firms to do this? (no, finding multilingual
"friends" to do same is far too unprofessional -- though they may
have value in proofing the results) I suspect there is some
value in having a single firm handle all of the translations
(in the hope that they will create a consistent SET of
translations, even if different individuals are involved for
each)

Relative effort? (i.e., closer to reading speed or writing speed?)

Time frame? (is this effort-bound or business-bound)

Cost? (and, "unit of measure"?)

Finally, how to check the translation for accuracy and "feel"
(i.e., ensuring it is true to the original intent)?

With translations in hand, do you (thereafter) maintain
individual documents? Or, merge them into a conditional
document?

Horror stories of attempts gone horribly wrong (i.e., what to
avoid)?

Thx!

On 22/12/2021 08:02, Don Y wrote:
> I'm looking for folks who've first hand experience having
> documents translated into foreign languages.  Said documents
> to include diagrams (think: callouts, legends), #included
> text, etc.

I have a friend who is a patent translator. They actually do into
English from several European languages that they are fluent in.

Advice is generally that the translator must be fluent in both (written
rather than spoken) and *very* strong preference that they are a native
speaker of the destination language in each case.

I was involved in porting software into Japanese a long time ago and it
was quite entertaining. The jump from 1 byte to 2 byte DBCS character
representation made things even more fun back then. But the worst part
was finding a technical translator that could understand domain specific
terms and give them the right nuance. eg. "Dwell time" caused trouble.
First pass it came out as "time in home" - there were lots of others.

In Japan it wasn't uncommon to meet perfectly good English to Japanese
translators who were just too shy to speak English even though they
could understand it perfectly well and write it almost fluently. In some
ways their knowledge of more complex English grammar was better than
many native English speakers today. Correct usage of "I would be obliged
if you could" vs "would" - there is a hidden insult in the first phrase
which has now sort of been lost in common English usage.

> I've a fair bit of experience with I18N/L10N for software
> but the extent of the effort, there, is usually fairly limited.
> And, there's less of a need for a cohesive approach as the
> interactions are "punctuated" (no pun intended).
>
> Recommendations for firms to do this?  (no, finding multilingual
> "friends" to do same is far too unprofessional -- though they may
> have value in proofing the results)  I suspect there is some
> value in having a single firm handle all of the translations
> (in the hope that they will create a consistent SET of
> translations, even if different individuals are involved for
> each)
>
> Relative effort?  (i.e., closer to reading speed or writing speed?)

The effort involved is quite high and gets higher and more expensive the
more important the documents are and the exact precision of technical
translation required. Patent translation is about the most extreme.

Many now use a hybrid machine translation human correction approach at
least in the UK where person hours are expensive. It works well if you
translate a lot of similar things with their own set of phrases (as
happens quite a lot in patents).
>
> Time frame? (is this effort-bound or business-bound)
>
> Cost?  (and, "unit of measure"?)
>
> Finally, how to check the translation for accuracy and "feel"
> (i.e., ensuring it is true to the original intent)?

These days machine translate back with eg Google and see if you can
recognise anything of what you had originally written. You really need
to have it all proof read by another native speaker of the language who
is a domain expert in whatever the content is. That way you find most of
the peculiar ambiguities that translation and punctuation can insert.

"Eats shoots and leaves" for example.
>
> With translations in hand, do you (thereafter) maintain
> individual documents?  Or, merge them into a conditional
> document?

The way we did it was have a separate set of documents and resource
files for the text components in each language and a language code. I
doubt if that part has changed. They get bigger with time. Then you can
add new phrases to the end as and when needed.

That way additional languages can be added easily if someone else is
willing to do the work.

> Horror stories of attempts gone horribly wrong (i.e., what to
> avoid)?

Translations by some willing amateur who is not a native speaker of the
destination language and which you are unable to check for veracity.
Think most Chinglish instruction manuals for cheap hitech gear.

--
Regards,
Martin Brown

On a sunny day (Wed, 22 Dec 2021 09:17:57 +0000) it happened Martin Brown
<'''newspam'''@nonad.co.uk> wrote in <spuqgd$q8b$1@gioia.aioe.org>:

>On 22/12/2021 08:02, Don Y wrote:
>> I'm looking for folks who've first hand experience having
>> documents translated into foreign languages.  Said documents
>> to include diagrams (think: callouts, legends), #included
>> text, etc.
>
>I have a friend who is a patent translator. They actually do into
>English from several European languages that they are fluent in.
>
>Advice is generally that the translator must be fluent in both (written
>rather than spoken) and *very* strong preference that they are a native
>speaker of the destination language in each case.
>
>I was involved in porting software into Japanese a long time ago and it
>was quite entertaining. The jump from 1 byte to 2 byte DBCS character
>representation made things even more fun back then. But the worst part
>was finding a technical translator that could understand domain specific
>terms and give them the right nuance. eg. "Dwell time" caused trouble.
>First pass it came out as "time in home" - there were lots of others.
>
>In Japan it wasn't uncommon to meet perfectly good English to Japanese
>translators who were just too shy to speak English even though they
>could understand it perfectly well and write it almost fluently. In some
>ways their knowledge of more complex English grammar was better than
>many native English speakers today. Correct usage of "I would be obliged
>if you could" vs "would" - there is a hidden insult in the first phrase
>which has now sort of been lost in common English usage.
>
>> I've a fair bit of experience with I18N/L10N for software
>> but the extent of the effort, there, is usually fairly limited.
>> And, there's less of a need for a cohesive approach as the
>> interactions are "punctuated" (no pun intended).
>>
>> Recommendations for firms to do this?  (no, finding multilingual
>> "friends" to do same is far too unprofessional -- though they may
>> have value in proofing the results)  I suspect there is some
>> value in having a single firm handle all of the translations
>> (in the hope that they will create a consistent SET of
>> translations, even if different individuals are involved for
>> each)
>>
>> Relative effort?  (i.e., closer to reading speed or writing speed?)
>
>The effort involved is quite high and gets higher and more expensive the
>more important the documents are and the exact precision of technical
>translation required. Patent translation is about the most extreme.
>
>Many now use a hybrid machine translation human correction approach at
>least in the UK where person hours are expensive. It works well if you
>translate a lot of similar things with their own set of phrases (as
>happens quite a lot in patents).
>>
>> Time frame? (is this effort-bound or business-bound)
>>
>> Cost?  (and, "unit of measure"?)
>>
>> Finally, how to check the translation for accuracy and "feel"
>> (i.e., ensuring it is true to the original intent)?
>
>These days machine translate back with eg Google and see if you can
>recognise anything of what you had originally written. You really need
>to have it all proof read by another native speaker of the language who
>is a domain expert in whatever the content is. That way you find most of
>the peculiar ambiguities that translation and punctuation can insert.
>
>"Eats shoots and leaves" for example.
>>
>> With translations in hand, do you (thereafter) maintain
>> individual documents?  Or, merge them into a conditional
>> document?
>
>The way we did it was have a separate set of documents and resource
>files for the text components in each language and a language code. I
>doubt if that part has changed. They get bigger with time. Then you can
>add new phrases to the end as and when needed.
>
>That way additional languages can be added easily if someone else is
>willing to do the work.
>
>> Horror stories of attempts gone horribly wrong (i.e., what to
>> avoid)?
>
>Translations by some willing amateur who is not a native speaker of the
>destination language and which you are unable to check for veracity.
>Think most Chinglish instruction manuals for cheap hitech gear.

I have done technical Dutch English from lab reports to service documentation for Philips military.
But I had a secretary to fix my spelling back then :-)
When was that, early seventies... Satellite communication systems..

On 2021-12-22 10:17, Martin Brown wrote:
> [...] In some ways their knowledge of more complex English
> grammar was better than many native English speakers today. Correct
> usage of "I would be obliged if you could" vs "would" - there is a
> hidden insult in the first phrase which has now sort of been lost in
> common English usage.
[...]

Would you elaborate on that a little? The nuance escapes me.
Is it that 'could' throws doubt on the other's ability?

Jeroen Belleman

On 12/22/2021 2:50 AM, Jeroen Belleman wrote:
> On 2021-12-22 10:17, Martin Brown wrote:
>> [...] In some ways their knowledge of more complex English
>> grammar was better than many native English speakers today. Correct
>> usage of "I would be obliged if you could" vs "would" - there is a
>> hidden insult in the first phrase which has now sort of been lost in
>> common English usage.
> [...]
>
> Would you elaborate on that a little? The nuance escapes me.
> Is it that 'could' throws doubt on the other's ability?

Yes. It's the "Can" vs. "May" issue.

There are innumerable other "technical screwups" that have crept into
the language that folks either are oblivious to or unconcerned with
fixing. (My personal pet peeve is the use of "what" in place of "that":
"He's the guy what sold me that lemon of a car!")

On 12/22/2021 2:17 AM, Martin Brown wrote:
> On 22/12/2021 08:02, Don Y wrote:
>> I'm looking for folks who've first hand experience having
>> documents translated into foreign languages. Said documents
>> to include diagrams (think: callouts, legends), #included
>> text, etc.
>
> I have a friend who is a patent translator. They actually do into English from
> several European languages that they are fluent in.
>
> Advice is generally that the translator must be fluent in both (written rather
> than spoken) and *very* strong preference that they are a native speaker of the
> destination language in each case.

This suggests N translators for N languages.

> I was involved in porting software into Japanese a long time ago and it was
> quite entertaining. The jump from 1 byte to 2 byte DBCS character
> representation made things even more fun back then. But the worst part was
> finding a technical translator that could understand domain specific terms and
> give them the right nuance. eg. "Dwell time" caused trouble.
> First pass it came out as "time in home" - there were lots of others.
>
> In Japan it wasn't uncommon to meet perfectly good English to Japanese
> translators who were just too shy to speak English even though they could
> understand it perfectly well and write it almost fluently. In some ways their
> knowledge of more complex English grammar was better than many native English
> speakers today. Correct usage of "I would be obliged if you could" vs "would" -
> there is a hidden insult in the first phrase which has now sort of been lost in
> common English usage.

Yes, I had a neighbor who was native Japanese and her husband spoke it
fluently (having lived there for many years "teaching english"). He
tried explaining the different "styles" of Japanese speaking (e.g.,
from what we'd consider "colloquial" to "audience with the Emperor")

>> I've a fair bit of experience with I18N/L10N for software
>> but the extent of the effort, there, is usually fairly limited.
>> And, there's less of a need for a cohesive approach as the
>> interactions are "punctuated" (no pun intended).
>>
>> Recommendations for firms to do this? (no, finding multilingual
>> "friends" to do same is far too unprofessional -- though they may
>> have value in proofing the results) I suspect there is some
>> value in having a single firm handle all of the translations
>> (in the hope that they will create a consistent SET of
>> translations, even if different individuals are involved for
>> each)
>>
>> Relative effort? (i.e., closer to reading speed or writing speed?)
>
> The effort involved is quite high and gets higher and more expensive the more
> important the documents are and the exact precision of technical translation
> required. Patent translation is about the most extreme.

But I would imagine highly technical is easier to verify correctness.
Less formal prose would rely on the translator understanding colloquialisms,
analogies, etc. I.e., the *intent* of the prose.

There also seems to be a fair bit of "cultural" risk involved.

[I recall making a version of an arcade game for export and
finding that the skull-and-crossbones used to signify the
death of a player was highly discouraged in some markets
whereas the US market wouldn't even shrug at the iconography]

I'm also concerned that graphs/illustrations may require
alteration to accommodate different string lengths, etc.

> Many now use a hybrid machine translation human correction approach at least in
> the UK where person hours are expensive. It works well if you translate a lot
> of similar things with their own set of phrases (as happens quite a lot in
> patents).
>>
>> Time frame? (is this effort-bound or business-bound)
>>
>> Cost? (and, "unit of measure"?)
>>
>> Finally, how to check the translation for accuracy and "feel"
>> (i.e., ensuring it is true to the original intent)?
>
> These days machine translate back with eg Google and see if you can recognise
> anything of what you had originally written. You really need to have it all
> proof read by another native speaker of the language who is a domain expert in
> whatever the content is. That way you find most of the peculiar ambiguities
> that translation and punctuation can insert.

Exactly. So, it's like finding *two* service bureaus instead of just one.

Any value to having a second group translate back into the original language?

> "Eats shoots and leaves" for example.
>>
>> With translations in hand, do you (thereafter) maintain
>> individual documents? Or, merge them into a conditional
>> document?
>
> The way we did it was have a separate set of documents and resource files for
> the text components in each language and a language code. I doubt if that part
> has changed. They get bigger with time. Then you can add new phrases to the end
> as and when needed.
>
> That way additional languages can be added easily if someone else is willing to
> do the work.

I don't understand. Are you building a translation *dictionary* that you
apply to create the document(s)?

>> Horror stories of attempts gone horribly wrong (i.e., what to
>> avoid)?
>
> Translations by some willing amateur who is not a native speaker of the
> destination language and which you are unable to check for veracity. Think most
> Chinglish instruction manuals for cheap hitech gear.

Yes, exactly. But, that would be easy to avoid.

The bigger fear is hiring a service bureau and later discovering they
were little better than mechanical translators (again, because "you"
likely can't review the result, directly).

On 22/12/2021 10:47, Don Y wrote:
> On 12/22/2021 2:17 AM, Martin Brown wrote:
>> On 22/12/2021 08:02, Don Y wrote:
>>> I'm looking for folks who've first hand experience having
>>> documents translated into foreign languages.  Said documents
>>> to include diagrams (think: callouts, legends), #included
>>> text, etc.
>>
>> I have a friend who is a patent translator. They actually do into
>> English from several European languages that they are fluent in.
>>
>> Advice is generally that the translator must be fluent in both
>> (written rather than spoken) and *very* strong preference that they
>> are a native speaker of the destination language in each case.
>
> This suggests N translators for N languages.

If you have an idea what you want they tend to form clubs that allow
them to do a combination of different languages and load share. My
friend used to run a translation bureau for the same sort of work before
she went freelance as part of a group. There is a UK translators club
with verified exam standard pieces. I expect it is similar in the USA.
>
>> I was involved in porting software into Japanese a long time ago and
>> it was quite entertaining. The jump from 1 byte to 2 byte DBCS
>> character representation made things even more fun back then. But the
>> worst part was finding a technical translator that could understand
>> domain specific terms and give them the right nuance. eg. "Dwell time"
>> caused trouble.
>> First pass it came out as "time in home" - there were lots of others.
>>
>> In Japan it wasn't uncommon to meet perfectly good English to Japanese
>> translators who were just too shy to speak English even though they
>> could understand it perfectly well and write it almost fluently. In
>> some ways their knowledge of more complex English grammar was better
>> than many native English speakers today. Correct usage of "I would be
>> obliged if you could" vs "would" - there is a hidden insult in the
>> first phrase which has now sort of been lost in common English usage.
>
> Yes, I had a neighbor who was native Japanese and her husband spoke it
> fluently (having lived there for many years "teaching english").  He
> tried explaining the different "styles" of Japanese speaking (e.g.,
> from what we'd consider "colloquial" to "audience with the Emperor")

Yes. Using the wrong highly formal method of address can come across as
incredibly sarcastic or demeaning if you get it wrong. There is a more
neutral form which is safe enough for foreigners to get away with.

>>> Relative effort?  (i.e., closer to reading speed or writing speed?)
>>
>> The effort involved is quite high and gets higher and more expensive
>> the more important the documents are and the exact precision of
>> technical translation required. Patent translation is about the most
>> extreme.
>
> But I would imagine highly technical is easier to verify correctness.
> Less formal prose would rely on the translator understanding
> colloquialisms,
> analogies, etc.  I.e., the *intent* of the prose.

Its the ones that you are not aware of that catch you out. Where a
phrase in English has a literal translation in the destination language
that has another unintended or unwanted meaning.
eg. Nova cars in Spanish.

> There also seems to be a fair bit of "cultural" risk involved.

Best one I recall was a before and after photo advert for washing powder
designed by a Western ad agency but used in a country where they read
right to left. Why would anyone buy a powder that turns clean clothes dirty!

> I'm also concerned that graphs/illustrations may require
> alteration to accommodate different string lengths, etc.

We had some real difficulties with feet & inches on engineering diagrams
when a US buyout meant that they had to be supported in a previously
entirely metric system with decimals engineering design software.

>> Many now use a hybrid machine translation human correction approach at
>> least in the UK where person hours are expensive. It works well if you
>> translate a lot of similar things with their own set of phrases (as
>> happens quite a lot in patents).
>>>
>>> Time frame? (is this effort-bound or business-bound)
>>>
>>> Cost?  (and, "unit of measure"?)
>>>
>>> Finally, how to check the translation for accuracy and "feel"
>>> (i.e., ensuring it is true to the original intent)?
>>
>> These days machine translate back with eg Google and see if you can
>> recognise anything of what you had originally written. You really need
>> to have it all proof read by another native speaker of the language
>> who is a domain expert in whatever the content is. That way you find
>> most of the peculiar ambiguities that translation and punctuation can
>> insert.
>
> Exactly.  So, it's like finding *two* service bureaus instead of just one.
>
> Any value to having a second group translate back into the original
> language?

Not really. Having a native speaker proof read it for unwanted
ambiguities checked against the English original is worthwhile though.

Google translate might be good enough these days to give you enough
hints of where things might well have gone awry.

Many technical terms look similar in most languages (except French where
the language police insist that software is logiciel hence Logitech).

>> "Eats shoots and leaves" for example.
>>>
>>> With translations in hand, do you (thereafter) maintain
>>> individual documents?  Or, merge them into a conditional
>>> document?
>>
>> The way we did it was have a separate set of documents and resource
>> files for the text components in each language and a language code. I
>> doubt if that part has changed. They get bigger with time. Then you
>> can add new phrases to the end as and when needed.
>>
>> That way additional languages can be added easily if someone else is
>> willing to do the work.
>
> I don't understand.  Are you building a translation *dictionary* that you
> apply to create the document(s)?

Not a dictionary so much as a set of key phrases that will appear in
dialogue boxes in the software - each having a unique numeric token.

It is also a part of the way the computer assisted translation engines
work for commonly used constructs.

>>> Horror stories of attempts gone horribly wrong (i.e., what to
>>> avoid)?
>>
>> Translations by some willing amateur who is not a native speaker of
>> the destination language and which you are unable to check for
>> veracity. Think most Chinglish instruction manuals for cheap hitech gear.
>
> Yes, exactly.  But, that would be easy to avoid.
>
> The bigger fear is hiring a service bureau and later discovering they
> were little better than mechanical translators (again, because "you"
> likely can't review the result, directly).

I think you have to ask around for recommendations in the territory or
where you want to have the work done. Some of our translations were done
by the national distributors (Korean for instance) and seemed to go OK.
The big jumps were doing the first non-English one that included accents
and top bit set characters and then the Japanese one with full DBCS. It
got a bit easier after that.

There is a lot more support for internationalisation DBCS these days.

--
Regards,
Martin Brown

Don Y wrote:
> On 12/22/2021 2:50 AM, Jeroen Belleman wrote:
>> On 2021-12-22 10:17, Martin Brown wrote:
>>> [...]  In some ways their knowledge of more complex English
>>> grammar was better than many native English speakers today. Correct
>>> usage of "I would be obliged if you could" vs "would" - there is a
>>> hidden insult in the first phrase which has now sort of been lost in
>>> common English usage.
>>   [...]
>>
>> Would you elaborate on that a little? The nuance escapes me.
>> Is it that 'could' throws doubt on the other's ability?
>
> Yes.  It's the "Can" vs. "May" issue.
>
> There are innumerable other "technical screwups" that have crept into
> the language that folks either are oblivious to or unconcerned with
> fixing.  (My personal pet peeve is the use of "what" in place of "that":
> "He's the guy what sold me that lemon of a car!")

Interesting. OTSOTP saying "could you do X" is polite by itself, but
"would you do X" needs a 'please'.

The implication of 'could' includes "of course you would if it were
possible", which it might not be, e.g. by reasons of time, authority,
law, and so forth. In contrast, over here 'would' sounds like 'of
course you could if you actually wanted to help me, but maybe you don't
care enough.'

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

On a sunny day (Wed, 22 Dec 2021 07:51:29 -0500) it happened Phil Hobbs
<pcdhSpamMeSenseless@electrooptical.net> wrote in
<b96443b3-03a8-8b25-024e-138cde7329b0@electrooptical.net>:

>Don Y wrote:
>> On 12/22/2021 2:50 AM, Jeroen Belleman wrote:
>>> On 2021-12-22 10:17, Martin Brown wrote:
>>>> [...]  In some ways their knowledge of more complex English
>>>> grammar was better than many native English speakers today. Correct
>>>> usage of "I would be obliged if you could" vs "would" - there is a
>>>> hidden insult in the first phrase which has now sort of been lost in
>>>> common English usage.
>>>   [...]
>>>
>>> Would you elaborate on that a little? The nuance escapes me.
>>> Is it that 'could' throws doubt on the other's ability?
>>
>> Yes.  It's the "Can" vs. "May" issue.
>>
>> There are innumerable other "technical screwups" that have crept into
>> the language that folks either are oblivious to or unconcerned with
>> fixing.  (My personal pet peeve is the use of "what" in place of "that":
>> "He's the guy what sold me that lemon of a car!")
>
>Interesting. OTSOTP saying "could you do X" is polite by itself, but
>"would you do X" needs a 'please'.
>
>The implication of 'could' includes "of course you would if it were
>possible", which it might not be, e.g. by reasons of time, authority,
>law, and so forth. In contrast, over here 'would' sounds like 'of
>course you could if you actually wanted to help me, but maybe you don't
>care enough.'
>
>Cheers
>
>Phil Hobbs

https://songteksten.net/lyric/400/67817/simon-garfunkel/el-condor-pasa.html
and he sailed away faster than the wind...

Jan Panteltje wrote:
> On a sunny day (Wed, 22 Dec 2021 07:51:29 -0500) it happened Phil Hobbs
> <pcdhSpamMeSenseless@electrooptical.net> wrote in
> <b96443b3-03a8-8b25-024e-138cde7329b0@electrooptical.net>:
>
>> Don Y wrote:
>>> On 12/22/2021 2:50 AM, Jeroen Belleman wrote:
>>>> On 2021-12-22 10:17, Martin Brown wrote:
>>>>> [...]  In some ways their knowledge of more complex English
>>>>> grammar was better than many native English speakers today. Correct
>>>>> usage of "I would be obliged if you could" vs "would" - there is a
>>>>> hidden insult in the first phrase which has now sort of been lost in
>>>>> common English usage.
>>>>   [...]
>>>>
>>>> Would you elaborate on that a little? The nuance escapes me.
>>>> Is it that 'could' throws doubt on the other's ability?
>>>
>>> Yes.  It's the "Can" vs. "May" issue.
>>>
>>> There are innumerable other "technical screwups" that have crept into
>>> the language that folks either are oblivious to or unconcerned with
>>> fixing.  (My personal pet peeve is the use of "what" in place of "that":
>>> "He's the guy what sold me that lemon of a car!")
>>
>> Interesting. OTSOTP saying "could you do X" is polite by itself, but
>> "would you do X" needs a 'please'.
>>
>> The implication of 'could' includes "of course you would if it were
>> possible", which it might not be, e.g. by reasons of time, authority,
>> law, and so forth. In contrast, over here 'would' sounds like 'of
>> course you could if you actually wanted to help me, but maybe you don't
>> care enough.'
>>
>> Cheers
>>
>> Phil Hobbs
>
> https://songteksten.net/lyric/400/67817/simon-garfunkel/el-condor-pasa.html
> and he sailed away faster than the wind...
>

I'd rather be a hammer than a nail too. (A kinder, gentler sort of
hammer, of course.) ;)

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

On 2021/12/22 2:47 a.m., Don Y wrote:
> On 12/22/2021 2:17 AM, Martin Brown wrote:
>> On 22/12/2021 08:02, Don Y wrote:
>>> I'm looking for folks who've first hand experience having
>>> documents translated into foreign languages.  Said documents
>>> to include diagrams (think: callouts, legends), #included
>>> text, etc.
>>
>> I have a friend who is a patent translator. They actually do into
>> English from several European languages that they are fluent in.
>>
>> Advice is generally that the translator must be fluent in both
>> (written rather than spoken) and *very* strong preference that they
>> are a native speaker of the destination language in each case.
>
> This suggests N translators for N languages.
>
>> I was involved in porting software into Japanese a long time ago and
>> it was quite entertaining. The jump from 1 byte to 2 byte DBCS
>> character representation made things even more fun back then. But the
>> worst part was finding a technical translator that could understand
>> domain specific terms and give them the right nuance. eg. "Dwell time"
>> caused trouble.
>> First pass it came out as "time in home" - there were lots of others.
>>
>> In Japan it wasn't uncommon to meet perfectly good English to Japanese
>> translators who were just too shy to speak English even though they
>> could understand it perfectly well and write it almost fluently. In
>> some ways their knowledge of more complex English grammar was better
>> than many native English speakers today. Correct usage of "I would be
>> obliged if you could" vs "would" - there is a hidden insult in the
>> first phrase which has now sort of been lost in common English usage.
>
> Yes, I had a neighbor who was native Japanese and her husband spoke it
> fluently (having lived there for many years "teaching english").  He
> tried explaining the different "styles" of Japanese speaking (e.g.,
> from what we'd consider "colloquial" to "audience with the Emperor")
Not to mention masculine vs feminine Japanese - a person speaks slightly
different languages depending on the gender of the speaker. I have no
idea if that percolates down into technical matters...
My ex is Japanese and in the 90s she was one of two bi-directional
accredited translators (Japanese - English) in British Columbia, Canada.
John :-#)#

On 2021-12-22 11:33, Don Y wrote:
> On 12/22/2021 2:50 AM, Jeroen Belleman wrote:
>> On 2021-12-22 10:17, Martin Brown wrote:
>>> [...] In some ways their knowledge of more complex English
>>> grammar was better than many native English speakers today. Correct
>>> usage of "I would be obliged if you could" vs "would" - there is a
>>> hidden insult in the first phrase which has now sort of been lost in
>>> common English usage.
>> [...]
>>
>> Would you elaborate on that a little? The nuance escapes me.
>> Is it that 'could' throws doubt on the other's ability?
>
> Yes. It's the "Can" vs. "May" issue.
>
> There are innumerable other "technical screwups" that have crept into
> the language that folks either are oblivious to or unconcerned with
> fixing. (My personal pet peeve is the use of "what" in place of "that":
> "He's the guy what sold me that lemon of a car!")

Indeed. I still think it's supposed to be "He's the guy /who/ ...".
That may be British rather than American English. Languages evolve.

Jeroen Belleman

On 12/22/2021 8:56 AM, Jeroen Belleman wrote:
> On 2021-12-22 11:33, Don Y wrote:
>> On 12/22/2021 2:50 AM, Jeroen Belleman wrote:
>>> On 2021-12-22 10:17, Martin Brown wrote:
>>>> [...] In some ways their knowledge of more complex English
>>>> grammar was better than many native English speakers today. Correct
>>>> usage of "I would be obliged if you could" vs "would" - there is a
>>>> hidden insult in the first phrase which has now sort of been lost in
>>>> common English usage.
>>> [...]
>>>
>>> Would you elaborate on that a little? The nuance escapes me.
>>> Is it that 'could' throws doubt on the other's ability?
>>
>> Yes. It's the "Can" vs. "May" issue.
>>
>> There are innumerable other "technical screwups" that have crept into
>> the language that folks either are oblivious to or unconcerned with
>> fixing. (My personal pet peeve is the use of "what" in place of "that":
>> "He's the guy what sold me that lemon of a car!")
>
> Indeed. I still think it's supposed to be "He's the guy /who/ ...".
> That may be British rather than American English. Languages evolve.

It would be a tough call to determine if American English had evolved more
OR LESS than the original British. I've read that American English is, in
many ways, truer to its British roots than modern British English.

Pronunciations also evolve, over time. As well as speech patterns.

E.g., I was taught "the" should be pronounced as "thee" when preceding
a word beginning with a vowel sound: "Thee English", "Thee other guy"
but with a schwa ahead of a consonant: "The next one", "the Frenchman".
This seems to no longer be the norm.

[You're interested in these sorts of things when you design a
speech synthesizer; the different "wh" sounds, etc.]

Jeroen Belleman wrote:
> On 2021-12-22 11:33, Don Y wrote:
>> On 12/22/2021 2:50 AM, Jeroen Belleman wrote:
>>> On 2021-12-22 10:17, Martin Brown wrote:
>>>> [...]  In some ways their knowledge of more complex English
>>>> grammar was better than many native English speakers today. Correct
>>>> usage of "I would be obliged if you could" vs "would" - there is a
>>>> hidden insult in the first phrase which has now sort of been lost in
>>>> common English usage.
>>>   [...]
>>>
>>> Would you elaborate on that a little? The nuance escapes me.
>>> Is it that 'could' throws doubt on the other's ability?
>>
>> Yes.  It's the "Can" vs. "May" issue.
>>
>> There are innumerable other "technical screwups" that have crept into
>> the language that folks either are oblivious to or unconcerned with
>> fixing.  (My personal pet peeve is the use of "what" in place of "that":
>> "He's the guy what sold me that lemon of a car!")
>
> Indeed. I still think it's supposed to be "He's the guy /who/ ...".
> That may be British rather than American English. Languages evolve.
>
> Jeroen Belleman
>

"The guy what sold me..." would mark the speaker as illiterate anywhere
in the northern US AFAIK, except in parts of the Bronx or Staten Island,
northeastern New Jersey, and maybe outer Brooklyn.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

On Wed, 22 Dec 2021 11:34:57 -0500, Phil Hobbs
<pcdhSpamMeSenseless@electrooptical.net> wrote:

>Jeroen Belleman wrote:
>> On 2021-12-22 11:33, Don Y wrote:
>>> On 12/22/2021 2:50 AM, Jeroen Belleman wrote:
>>>> On 2021-12-22 10:17, Martin Brown wrote:
>>>>> [...]  In some ways their knowledge of more complex English
>>>>> grammar was better than many native English speakers today. Correct
>>>>> usage of "I would be obliged if you could" vs "would" - there is a
>>>>> hidden insult in the first phrase which has now sort of been lost in
>>>>> common English usage.
>>>>   [...]
>>>>
>>>> Would you elaborate on that a little? The nuance escapes me.
>>>> Is it that 'could' throws doubt on the other's ability?
>>>
>>> Yes.  It's the "Can" vs. "May" issue.
>>>
>>> There are innumerable other "technical screwups" that have crept into
>>> the language that folks either are oblivious to or unconcerned with
>>> fixing.  (My personal pet peeve is the use of "what" in place of "that":
>>> "He's the guy what sold me that lemon of a car!")
>>
>> Indeed. I still think it's supposed to be "He's the guy /who/ ...".
>> That may be British rather than American English. Languages evolve.
>>
>> Jeroen Belleman
>>
>
>"The guy what sold me..." would mark the speaker as illiterate anywhere
>in the northern US AFAIK, except in parts of the Bronx or Staten Island,
>northeastern New Jersey, and maybe outer Brooklyn.
>
>Cheers
>
>Phil Hobbs

"Done sold me" is the past tense.

It's comprehensible. Just a regional variant, likely not correlated to
literacy.

--

I yam what I yam - Popeye

On a sunny day (Wed, 22 Dec 2021 09:30:43 -0700) it happened Don Y
<blockedofcourse@foo.invalid> wrote in <spvjrv$tj1$1@dont-email.me>:

>It would be a tough call to determine if American English had evolved more
>OR LESS than the original British. I've read that American English is, in
>many ways, truer to its British roots than modern British English.
>
>Pronunciations also evolve, over time. As well as speech patterns.
>
>E.g., I was taught "the" should be pronounced as "thee" when preceding
>a word beginning with a vowel sound: "Thee English", "Thee other guy"
>but with a schwa ahead of a consonant: "The next one", "the Frenchman".
>This seems to no longer be the norm.
>
>[You're interested in these sorts of things when you design a
>speech synthesizer; the different "wh" sounds, etc.]

A pretty decent text to speech is google translate.

This script, called gst2_en on my system, has a female talk in english:

#!/bin/bash
say() { local IFS=+;/usr/bin/mplayer -ao alsa -really-quiet -noconsolecontrols "http://translate.google.com/translate_tts?ie=UTF-8&client=tw-ob&q=$*&tl=en"; }
say $*

You call it like this (with your text as example):
gst2_en ">E.g., I was taught "the" should be pronounced as "thee" when preceding"

In the script the &tl=en can be changed for the language you want, so &tl=nl for Dutch and &tl=de for German.

If you want the output to go to a mp3 file then use mplayer -dumpstream in that script.

I find the quality better than other things I have tried.

All Linux of course

jlarkin@highlandsniptechnology.com wrote:
> On Wed, 22 Dec 2021 11:34:57 -0500, Phil Hobbs
> <pcdhSpamMeSenseless@electrooptical.net> wrote:
>
>> Jeroen Belleman wrote:
>>> On 2021-12-22 11:33, Don Y wrote:
>>>> On 12/22/2021 2:50 AM, Jeroen Belleman wrote:
>>>>> On 2021-12-22 10:17, Martin Brown wrote:
>>>>>> [...]  In some ways their knowledge of more complex English
>>>>>> grammar was better than many native English speakers today. Correct
>>>>>> usage of "I would be obliged if you could" vs "would" - there is a
>>>>>> hidden insult in the first phrase which has now sort of been lost in
>>>>>> common English usage.
>>>>>   [...]
>>>>>
>>>>> Would you elaborate on that a little? The nuance escapes me.
>>>>> Is it that 'could' throws doubt on the other's ability?
>>>>
>>>> Yes.  It's the "Can" vs. "May" issue.
>>>>
>>>> There are innumerable other "technical screwups" that have crept into
>>>> the language that folks either are oblivious to or unconcerned with
>>>> fixing.  (My personal pet peeve is the use of "what" in place of "that":
>>>> "He's the guy what sold me that lemon of a car!")
>>>
>>> Indeed. I still think it's supposed to be "He's the guy /who/ ...".
>>> That may be British rather than American English. Languages evolve.
>>>
>>> Jeroen Belleman
>>>
>>
>> "The guy what sold me..." would mark the speaker as illiterate anywhere
>> in the northern US AFAIK, except in parts of the Bronx or Staten Island,
>> northeastern New Jersey, and maybe outer Brooklyn.
>>
>> Cheers
>>
>> Phil Hobbs
>
> "Done sold me" is the past tense.
>
> It's comprehensible. Just a regional variant, likely not correlated to
> literacy.

"Done sold me" is more of a Southernism, no? You don't hear that round
here, anyway.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

On Wed, 22 Dec 2021 01:02:44 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

>I'm looking for folks who've first hand experience having
>documents translated into foreign languages. Said documents
>to include diagrams (think: callouts, legends), #included
>text, etc.
>
>I've a fair bit of experience with I18N/L10N for software
>but the extent of the effort, there, is usually fairly limited.
>And, there's less of a need for a cohesive approach as the
>interactions are "punctuated" (no pun intended).
>
>Recommendations for firms to do this? (no, finding multilingual
>"friends" to do same is far too unprofessional -- though they may
>have value in proofing the results) I suspect there is some
>value in having a single firm handle all of the translations
>(in the hope that they will create a consistent SET of
>translations, even if different individuals are involved for
>each)
>
>Relative effort? (i.e., closer to reading speed or writing speed?)

Writing speed. Fluency in the technical domain, plus native fluency in
the target language, are both necessary.

>Time frame? (is this effort-bound or business-bound)
>
>Cost? (and, "unit of measure"?)

Slow and expensive.

>Finally, how to check the translation for accuracy and "feel"
>(i.e., ensuring it is true to the original intent)?

Always need a proof reader and a tech editor in the target language;
need not be capable of translation.

>With translations in hand, do you (thereafter) maintain
>individual documents? Or, merge them into a conditional
>document?
Same as for the original document, but in versions. With luck, the
drawings are in common.

>Horror stories of attempts gone horribly wrong (i.e., what to
>avoid)?

Only on the receiving end so far. Here, I do have a war story from
the 1970s:

I was considering how to interface a typewriter-like printer made by
ABB or the like, and so was studying the English-language interface
manual, with text and sequence diagrams and the like.

It read like perfectly good English, but was incomprehensible. So, I
ignored the text and studied the figures. Whereupon it became clear
how that interface worked, and a bit later what was wrong with the
text.

Unlike English, all Swedish pronouns are gendered, which gender is
grammatical and has little to do with actual gender. Which means that
in a Swedish sentence one can carry about twice as many pronoun
reference without ambiguity than in English.

Well, you guessed it -- what had happened is that Swedish pronouns
were all directly 2:1 mapped to the corresponding English pronoun,
without recasting the sentences to remove the now massive ambiguities.

And that interface turned out to be too complicated for what it was,
so I gave up on that printer.

Another translation issue came up maybe 5 years ago, when we were
using a FPGA board from a Danish vendor. Their user manual was maybe
10 pages long, incomprehensible in many places, and a factor ten too
short to adequately describe the board and how to implement your stuff
on it. It had been written by harried Danish engineers and perhaps a
tech editor in English, their second language.

My advice to the President of the Danish firm was to have his
engineers write the first draft in Danish, and hire a tech editor
whose native language is English to make the translation and perform
the cleanup. The tech writer was allowed to question the engineers
until the editor understood, so the editor in effect stood in for the
English-speaking customer audience. This was done. I did a full
tech-edit scan of the result, and it read very well, and was perfectly
clear. Only needed to fix one usage problem. It still was not large
enough to fully describe that product, but still this was great
progress.

Joe Gwinn

On 12/22/2021 5:09 AM, Martin Brown wrote:
>>>> With translations in hand, do you (thereafter) maintain
>>>> individual documents? Or, merge them into a conditional
>>>> document?

----^^^^^^^^

>>> The way we did it was have a separate set of documents and resource files
>>> for the text components in each language and a language code. I doubt if
>>> that part has changed. They get bigger with time. Then you can add new
>>> phrases to the end as and when needed.
>>>
>>> That way additional languages can be added easily if someone else is willing
>>> to do the work.
>>
>> I don't understand. Are you building a translation *dictionary* that you
>> apply to create the document(s)?
>
> Not a dictionary so much as a set of key phrases that will appear in dialogue
> boxes in the software - each having a unique numeric token.
>
> It is also a part of the way the computer assisted translation engines work for
> commonly used constructs.

I was referring to how you prepare multilingual *documents*,
not executables.

E.g., you will often encounter things like "instruction manuals"
that have a section (pages) in English, followed by one in Spanish,
followed by...

AS IF they were separate documents strung together.

Alternatively, one can create a single document with the different
embedded within and *conditionally* expose one (or another). In
which case, the instruction manual would be generated by:

LANGUAGE=English
Print document
LANGUAGE=Spanish
Print document
LANGUAGE=...

My point is intended to address how you expose the translations to the
writer, charged with maintaining ALL of them (though likely with a
service bureau's assistance) as *each* is revised.

Separate documents seems like it would run the risk of certain languages
lagging in their currency.

>>>> Horror stories of attempts gone horribly wrong (i.e., what to
>>>> avoid)?
>>>
>>> Translations by some willing amateur who is not a native speaker of the
>>> destination language and which you are unable to check for veracity. Think
>>> most Chinglish instruction manuals for cheap hitech gear.
>>
>> Yes, exactly. But, that would be easy to avoid.
>>
>> The bigger fear is hiring a service bureau and later discovering they
>> were little better than mechanical translators (again, because "you"
>> likely can't review the result, directly).
>
> I think you have to ask around for recommendations in the territory or where
> you want to have the work done. Some of our translations were done by the
> national distributors (Korean for instance) and seemed to go OK. The big jumps
> were doing the first non-English one that included accents and top bit set
> characters and then the Japanese one with full DBCS. It got a bit easier after
> that.
>
> There is a lot more support for internationalisation DBCS these days.

Yes, I'm not worried about the "tools" but, rather, the "expertise".
I can create a document with 30 different "languages" (UTF-16) but
that doesn't mean *I* can tell you if what the document *says*
is correct, consistent, etc.

And, the shorter the text snippet, the worse the potential
"size change" as it undergoes translation (i.e., a *book* will
tend to see a smaller change in overall length than a single word)

So, callouts in figures are risky:

Imagine an illustrated volume annotated (in the obvious way) with:
length
width
height

In Armenian:
երկարություն
լայնությունը
բարձրություն

A naive author/illustrator would plan for the english text in
placing the legend/callout and be frustrated when the translator
provided these lengthier translations.

On 22/12/2021 20:21, Don Y wrote:

> A naive author/illustrator would plan for the english text in
> placing the legend/callout and be frustrated when the translator
> provided these lengthier translations.

Fixed field lengths always cause trouble. Your best bet is rescale the
text to fit the space and pray that it remains legible.

In hitech industries you do have a sporting chance that the skilled
technical people will be able to read some English (and may understand a
lot more spoken English than they let on during negotiations).

My wife's name contains phonemes that are all but impossible in Japanese
and her transliterated name overflowed the bank card field allowed.

Mine survived a little bit better as Ma-chin Buroun (roughly). The only
lonely consonant is "n" and some Romaji consonants are not available.

Most real Japanese names will fit in at most 5 characters (many just 4).

My company was taken over whilst we were there by a big UK company that
had a similar problem with its name being impossible to represent in
Japanese. They rebranded us (long established two easy phonemes company)
with their new snazzy Western name which was impossibly dumb in a
culture that values long established brands and relationships!
They went bust 5 years later. (I was well out of it by then)

--
Regards,
Martin Brown

On 12/22/2021 1:57 PM, Martin Brown wrote:
> On 22/12/2021 20:21, Don Y wrote:
>
>> A naive author/illustrator would plan for the english text in
>> placing the legend/callout and be frustrated when the translator
>> provided these lengthier translations.
>
> Fixed field lengths always cause trouble. Your best bet is rescale the text to
> fit the space and pray that it remains legible.

But in software, you are aware of a "field length" and can consciously
"pad" the length available in anticipation of "longer content".

By contrast, when you are illustrating something, you don't tend to
think "gee, I'd better locate this callout with a fair bit of empty
space surrounding IN CASE some other translation happens to require *more*
space. You'd not want to have to *redraw* an illustration just to
accommodate a "wider" callout.

> In hitech industries you do have a sporting chance that the skilled technical
> people will be able to read some English (and may understand a lot more spoken
> English than they let on during negotiations).

Things that are highly technical are usually not a problem; the target
audience can comprehend the "important words" (and skip over the fluff).
A datasheet being the simplest case of extracting content without having
a clue as to what the text proclaims!

The bigger problem is things that are more "reasoned" or presenting
arguments/rationales/side-effects/etc. These aren't usually as
terse and easy to parse to their intent.

> My wife's name contains phonemes that are all but impossible in Japanese and
> her transliterated name overflowed the bank card field allowed.

Kalahari? :>

You don't have to veer far from the european languages to find
gotchas in translations, odd (mis?)spellings, etc.

"Preservative" will raise eyebrows in french culture ("preservatif")

Polish tends to omit the V, X and Q graphemes. So, my friend Eva's name
is Ewa (I earned her friendship by being able to *spell* it when I first
met her; "Eva? As in E W A?"). And, of course, all vowels (or so it
seems :> )

Ditto the german F vs. V

> Mine survived a little bit better as Ma-chin Buroun (roughly). The only lonely
> consonant is "n" and some Romaji consonants are not available.
>
> Most real Japanese names will fit in at most 5 characters (many just 4).
>
> My company was taken over whilst we were there by a big UK company that had a
> similar problem with its name being impossible to represent in Japanese. They
> rebranded us (long established two easy phonemes company) with their new snazzy
> Western name which was impossibly dumb in a culture that values long
> established brands and relationships!
> They went bust 5 years later. (I was well out of it by then)

On 12/22/2021 10:15 AM, Jan Panteltje wrote:
> On a sunny day (Wed, 22 Dec 2021 09:30:43 -0700) it happened Don Y
> <blockedofcourse@foo.invalid> wrote in <spvjrv$tj1$1@dont-email.me>:
>
>> It would be a tough call to determine if American English had evolved more
>> OR LESS than the original British. I've read that American English is, in
>> many ways, truer to its British roots than modern British English.
>>
>> Pronunciations also evolve, over time. As well as speech patterns.
>>
>> E.g., I was taught "the" should be pronounced as "thee" when preceding
>> a word beginning with a vowel sound: "Thee English", "Thee other guy"
>> but with a schwa ahead of a consonant: "The next one", "the Frenchman".
>> This seems to no longer be the norm.
>>
>> [You're interested in these sorts of things when you design a
>> speech synthesizer; the different "wh" sounds, etc.]
>
> A pretty decent text to speech is google translate.
>
> This script, called gst2_en on my system, has a female talk in english:
>
> #!/bin/bash
> say() { local IFS=+;/usr/bin/mplayer -ao alsa -really-quiet -noconsolecontrols "http://translate.google.com/translate_tts?ie=UTF-8&client=tw-ob&q=$*&tl=en"; }
> say $*
>
>
>
> You call it like this (with your text as example):
> gst2_en ">E.g., I was taught "the" should be pronounced as "thee" when preceding"
>
> In the script the &tl=en can be changed for the language you want, so &tl=nl for Dutch and &tl=de for German.
>
> If you want the output to go to a mp3 file then use mplayer -dumpstream in that script.
>
> I find the quality better than other things I have tried.
>
> All Linux of course

There are lots of synthesizers out there -- FOSS as well as commercial.
But, those that run on a PC tend to be bloated implementations -- large
dictionaries, unit databases, etc. And, require a fair bit of CPU
to deliver speech in real-time. If you're trying to run in a small
footprint consuming very little "energy" (think tiny battery), there
really isn't much choice -- esp if you want to be able to tweek the voice
to suit the listeners' preferences (with unconstrained vocabulary)

And, all suffer from requiring some level of smarts at the application
level. Feed it "Blue orange dog cat run" or "Mr Mxyzptlk" or even
something as bland as "abcdefghijklmnopqrstuvwxyz" and they yield
results that are unfathomable -- without *looking* at the source text
to try to suss-out what they are *trying* to say.

On 12/22/2021 1:20 PM, Joe Gwinn wrote:
> On Wed, 22 Dec 2021 01:02:44 -0700, Don Y
> <blockedofcourse@foo.invalid> wrote:
>
>> I'm looking for folks who've first hand experience having
>> documents translated into foreign languages. Said documents
>> to include diagrams (think: callouts, legends), #included
>> text, etc.
>>
>> I've a fair bit of experience with I18N/L10N for software
>> but the extent of the effort, there, is usually fairly limited.
>> And, there's less of a need for a cohesive approach as the
>> interactions are "punctuated" (no pun intended).
>>
>> Recommendations for firms to do this? (no, finding multilingual
>> "friends" to do same is far too unprofessional -- though they may
>> have value in proofing the results) I suspect there is some
>> value in having a single firm handle all of the translations
>> (in the hope that they will create a consistent SET of
>> translations, even if different individuals are involved for
>> each)
>>
>> Relative effort? (i.e., closer to reading speed or writing speed?)
>
> Writing speed. Fluency in the technical domain, plus native fluency in
> the target language, are both necessary.

So, you are assuming there is no learning curve for the material?
Or, that the original author is conveniently available (and
communicative with translator) to resolve those issues as
they manifest?

>> Time frame? (is this effort-bound or business-bound)
>>
>> Cost? (and, "unit of measure"?)
>
> Slow and expensive.

But what is the unit of measure? Page? Job? How does it
scale? (e.g., if you bundle two 50 page documents together,
do you see a better price than if kept separate? Or, vs.
a 100pp document?)

>> Finally, how to check the translation for accuracy and "feel"
>> (i.e., ensuring it is true to the original intent)?
>
> Always need a proof reader and a tech editor in the target language;
> need not be capable of translation.

So, you have to ensure both the translator and the proofreader
comprehend the material (and presentation).

>> With translations in hand, do you (thereafter) maintain
>> individual documents? Or, merge them into a conditional
>> document?
> Same as for the original document, but in versions. With luck, the
> drawings are in common.

So, you're suggesting *different* documents (for each translation)?

>> Horror stories of attempts gone horribly wrong (i.e., what to
>> avoid)?

> Well, you guessed it -- what had happened is that Swedish pronouns
> were all directly 2:1 mapped to the corresponding English pronoun,
> without recasting the sentences to remove the now massive ambiguities.

So, this is a failure on the part of the translator(s).
And, likely, an "amateurish" one

> My advice to the President of the Danish firm was to have his
> engineers write the first draft in Danish, and hire a tech editor
> whose native language is English to make the translation and perform
> the cleanup. The tech writer was allowed to question the engineers
> until the editor understood, so the editor in effect stood in for the
> English-speaking customer audience. This was done. I did a full
> tech-edit scan of the result, and it read very well, and was perfectly
> clear. Only needed to fix one usage problem. It still was not large
> enough to fully describe that product, but still this was great
> progress.

I had an experience with a Japanese firm where the Japanese (vendor)
would simply (apparently!) update their existing documentation to reflect
my needs. This didn't instill confidence -- are they really changing
the product to meet those tighter specs? Or, just *claiming* to?

On 23/12/2021 00:21, Don Y wrote:
> On 12/22/2021 10:15 AM, Jan Panteltje wrote:
>> On a sunny day (Wed, 22 Dec 2021 09:30:43 -0700) it happened Don Y
>> <blockedofcourse@foo.invalid> wrote in <spvjrv$tj1$1@dont-email.me>:
>>
>>> It would be a tough call to determine if American English had evolved
>>> more
>>> OR LESS than the original British.  I've read that American English
>>> is, in
>>> many ways, truer to its British roots than modern British English.
>>>
>>> Pronunciations also evolve, over time.  As well as speech patterns.
>>>
>>> E.g., I was taught "the" should be pronounced as "thee" when preceding
>>> a word beginning with a vowel sound:  "Thee English", "Thee other guy"
>>> but with a schwa ahead of a consonant:  "The next one", "the Frenchman".
>>> This seems to no longer be the norm.
>>>
>>> [You're interested in these sorts of things when you design a
>>> speech synthesizer; the different "wh" sounds, etc.]
>>

[snip]
>> I find the quality better than other things I have tried.
>>
>> All Linux of course
>
> There are lots of synthesizers out there -- FOSS as well as commercial.
> But, those that run on a PC tend to be bloated implementations -- large
> dictionaries, unit databases, etc.  And, require a fair bit of CPU
> to deliver speech in real-time.  If you're trying to run in a small
> footprint consuming very little "energy" (think tiny battery), there
> really isn't much choice -- esp if you want to be able to tweek the voice
> to suit the listeners' preferences (with unconstrained vocabulary)
>
> And, all suffer from requiring some level of smarts at the application
> level.  Feed it "Blue orange dog cat run" or "Mr Mxyzptlk" or even
> something as bland as "abcdefghijklmnopqrstuvwxyz" and they yield
> results that are unfathomable -- without *looking* at the source text
> to try to suss-out what they are *trying* to say.

Place names with irregular pronunciation or including words that
synthesizers think they know tend to catch out even the most
sophisticated voice synthesisers.

Alexa can't manage for example Tyne & Wear (tine and weir), dialect
Chop Gate (chop yat) and Cholmondeley (Chumlee) catch out most
non-native English speakers in fact most non-locals. For that reason the
latter was a location for sensitive military intelligence during WWII.

https://en.wikipedia.org/wiki/Cholmondeley,_Cheshire#Cholmondeley_Castle_and_Park

--
Regards,
Martin Brown

On 23/12/2021 01:27, Don Y wrote:
> On 12/22/2021 1:20 PM, Joe Gwinn wrote:
>> On Wed, 22 Dec 2021 01:02:44 -0700, Don Y
>> <blockedofcourse@foo.invalid> wrote:
>>
>>> I'm looking for folks who've first hand experience having
>>> documents translated into foreign languages.  Said documents
>>> to include diagrams (think: callouts, legends), #included
>>> text, etc.
>>>
>>> I've a fair bit of experience with I18N/L10N for software
>>> but the extent of the effort, there, is usually fairly limited.
>>> And, there's less of a need for a cohesive approach as the
>>> interactions are "punctuated" (no pun intended).
>>>
>>> Recommendations for firms to do this?  (no, finding multilingual
>>> "friends" to do same is far too unprofessional -- though they may
>>> have value in proofing the results)  I suspect there is some
>>> value in having a single firm handle all of the translations
>>> (in the hope that they will create a consistent SET of
>>> translations, even if different individuals are involved for
>>> each)
>>>
>>> Relative effort?  (i.e., closer to reading speed or writing speed?)
>>
>> Writing speed. Fluency in the technical domain, plus native fluency in
>> the target language, are both necessary.
>
> So, you are assuming there is no learning curve for the material?
> Or, that the original author is conveniently available (and
> communicative with translator) to resolve those issues as
> they manifest?
>
>>> Time frame? (is this effort-bound or business-bound)
>>>
>>> Cost?  (and, "unit of measure"?)
>>
>> Slow and expensive.
>
> But what is the unit of measure?  Page?  Job?  How does it
> scale?  (e.g., if you bundle two 50 page documents together,
> do you see a better price than if kept separate?  Or, vs.
> a 100pp document?)

There is a fixed cost per job plus some per page or thousand words
depending on who you go to.
>
>>> Finally, how to check the translation for accuracy and "feel"
>>> (i.e., ensuring it is true to the original intent)?
>>
>> Always need a proof reader and a tech editor in the target language;
>> need not be capable of translation.
>
> So, you have to ensure both the translator and the proofreader
> comprehend the material (and presentation).

The translator doesn't necessarily need to fully understand the
technical stuff provided they can interact with someone who does.

>>> With translations in hand, do you (thereafter) maintain
>>> individual documents?  Or, merge them into a conditional
>>> document?
>>   Same as for the original document, but in versions.  With luck, the
>> drawings are in common.
>
> So, you're suggesting *different* documents (for each translation)?

Absolutely. There are horror stories of incompetent global edits being
made to documents containing hybrid mixed languages. Word collisions in
different languages are rare but not rare enough.

Have a script to merge them prior to publication/typesetting.

>>> Horror stories of attempts gone horribly wrong (i.e., what to
>>> avoid)?
>
>> Well, you guessed it -- what had happened is that Swedish pronouns
>> were all directly 2:1 mapped to the corresponding English pronoun,
>> without recasting the sentences to remove the now massive ambiguities.
>
> So, this is a failure on the part of the translator(s).
> And, likely, an "amateurish" one

Some languages have a lot more ambiguity than English and some are more
precise with specific orders for words in a sentence.

>> My advice to the President of the Danish firm was to have his
>> engineers write the first draft in Danish, and hire a tech editor
>> whose native language is English to make the translation and perform
>> the cleanup.  The tech writer was allowed to question the engineers
>> until the editor understood, so the editor in effect stood in for the
>> English-speaking customer audience.  This was done.  I did a full
>> tech-edit scan of the result, and it read very well, and was perfectly
>> clear.  Only needed to fix one usage problem.  It still was not large
>> enough to fully describe that product, but still this was great
>> progress.
>
> I had an experience with a Japanese firm where the Japanese (vendor)
> would simply (apparently!) update their existing documentation to reflect
> my needs.  This didn't instill confidence -- are they really changing
> the product to meet those tighter specs?  Or, just *claiming* to?

The Japanese vendor may well have tightened the specification to meet
what you had asked for or not. Hard to tell from your description. My
boss could never get his head round the fact that in Japanese
negotiations "yes" means little more than "I hear what you say".

And if you were unable to measure the difference between the product
before and after they "Improved" it then I think they have a point.

--
Regards,
Martin Brown