Re: lynx-dev Danish translation of lynx

[Henry Nelson]

> 1) As far as I can see, there is at most 78 characters in the
> translatable lines. Is this a limit which may not be exceeded, or
> is there a limit at 79 or 80 characters?
> 
> 2) Some strings are even filled up with spaces to exactly 78
> characters, like this one:
> 
> #. #define FORM_NOVICELINE_ONE
> #: LYMessages.c:175
> msgid ""
> "            Enter text into the field by typing on the keyboard     "
> msgstr ""
> 
> I suppose that the translation must be exactly the same length. Is
> this correct?

I will leave technical issues to the c literate developers.  From a
fellow translator's point of view:

1) No, the translation does not have to be the same length.  In the
early days, it used to have to be the same or shorter, but I believe now
it can be longer, although I am not sure of some absolute limit there may
be.  Almost none of the messages I have translated are the same as the
English string length.  Usually I strive to make them shorter.

2) In many cases you will want to strive for 78 characters (39 multi-byte)
characters _total_ if you are talking about status line messages since many
terminals can only display 80 characters max.

> 3) Are there other issues with regards to the length of
> translations that we must be aware of?

I go mostly by empirical testing, i.e., I run Lynx and look at what is
actually displayed.  I strive for "pleasing appearance" and "ease of
reading" in addition to clear and accurate (when possible) translation.

> 4) Some places the translatable strings are not whole sentences, but
> only single words. This is not good because the order of words vary
> from language to language.

A number of translators have said this.  Eventually the developers will
get the message, I hope.

> For example this code from LYExpandHostForURL() in LYUtils.c isn't
> good:
> 
>     if (LYCursesON) {
>         StrAllocCopy(MsgStr, WWW_FIND_MESSAGE);
>         StrAllocCat(MsgStr, host);
>         StrAllocCat(MsgStr, FIRST_SEGMENT);
>         HTProgress(MsgStr);
>     } else if (Startup && !dump_output_immediately) {
>         fprintf(stdout, "%s '%s'%s\n", WWW_FIND_MESSAGE, host, FIRST_SEGMENT);
[...]
> "Looking up 'some.host'" is in Danish:
> "Sl$BiS(B 'some.host' op".
> 
> "Looking up 'some.host' first" is
> "Sl$BiS(B f$B(Bst 'some.host' op".
> 
> "Looking up 'some.host.net', guessing..." is
> "Sl$BiS(B 'some.host.net' op, g$BkU(Bter...".
> 
> So you see that it is impossible or hard to make good translations

Hard sometimes, yes, but not impossible.  It's a challenge; that is true.
In general the programmers have not shown a lot of sympathy in the area
of syntax.  (Sometimes you think they got a meat grinder for Christmas.)

There are some tricks.  I don't understand Danish or why "Sl$BiS(B 'some.host'
op" might be good or bad, but you can effectively blank out that "first" and
"guessing" garbage by translating them, say ":" or "...", for example.  (Don't
just do "", because that will give you the default to the English string.)
Sometimes I use parentheses "()" for information that is worth translating,
but there is no work around for comprehensible syntax.  Perhaps there is a
single word in Danish to represent "Sl$BiS(B op", or by blanking out "Looking
up", it wouldn't be strange to do "'some.host' sl$BiS(B f$B(Bst op".  For
example, instead of "Looking up," "Trying" works well enough for all three
of those strings in Japanese, IMO.  There is no reason to be literal.  In
fact, the English of some of the messages is terrible and/or unclear in
meaning so that you can come up with much better messages in the NLS version.
I've even resorted to symbols of sorts when the translation is almost
impossible, something like "==>> 'some.host.net' ".

As a last resort, try looking at how other systems handle NLS.  I find the
Microsoft Windows98 NLS to be quite understandable.  You can see how they
are struggling with, and have overcome well in some cases, translations of
syntactically different languages.  Sun's Solaris is another example.  You
can get some hints.

__Henry

; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden