Re: [Docutils-develop] language set testing

[David G. <go...@py...>]

gr...@us... wrote:
> and maybe this should be more visible to translators not only
> a unittest, and could give warnings (verbose mode).

What do you mean?

>>> This is how i understood the datastructure, might be totally
>>> wrong.
>>
>> The "labels" dict can be xor-compared (it's a mapping of English
>> terms to terms in the given language), but the
>> "bibliographic_fields" dict cannot (it's a mapping of terms in the
>> given language to node classes).  You'll notice that all the
>> bibliographic_fields items failed for de.py, even though they're
>> correct.
>
> they failed because of first letter uppercase (i fixed this or
> did i break something ? another test required!)

I'm sorry, I mistakenly thought that "xor" was being applied to
"bibliographic_fields" in docutils/languages/de.py.

You're correct to have made the keys lowercase in
docutils/parsers/rst/languages/de.py.

BTW, de.py needs translations of the "raw", "include", and "replace"
directives.  Could you please?

There's a comment::

      'topic': 'topic',  # Inhalt, Thema or =DCberbegriff

There can be many keys with the same value.  Two of them anyway;
"inhalt" is already used for "contents".  Are they homonyms?

Another::

      'bild': 'image',
      'figure': 'figure', # also Bild ?

You can't use "bild" twice, but surely there's an appropriate word in
German?  Something like "titled-image" (translated) may suffice.  The
English "image" just means "picture", whereas "figure" has a larger
meaning, like "diagram/illustration/explanation".

I know no German, so I have to trust you as a native speaker to do
your best.  Just don't translate "contents" as "my hovercraft is full
of eels".  (Monty Python reference)

>> The length of "bibliographic_fields" also cannot be compared, since
>
> This was a try to test what might be possible, if not this
> will be removed.

Probably cannot be tested.

>> languages behave differently.  In Swedish there's no difference
>> between "Author" and "Authors", so there's one less entry.
>
> learned this from adam (maybe one could put comments in the file for
> the next peer)

Good idea.

>> If no parsers.rst.languages module exists for the
>> language, English is currently used as a fallback.
>
> tools/html.py -l de README.txt donotcare.html
...
>   File ".../docutils/parsers/rst/languages/__init__.py", line
> 19, in get_language
>     module =3D __import__(language_code, globals(), locals())
> ImportError: No module named de

Looks like a bug!  I should qualify: the *intention* is for English to
be used as a fallback for directive names.  Added to to-do/bugs.

>> In programming languages, most people seem to be happy with
>> English-based syntax.  AppleScript had language dialects, but I
>> don't think it caught on (code in Japanese looked *very* strange to
>> my eyes, but I'm biased).  Directives are similar to programming
>> language keywords/statements/commands, but not the same.  What do
>> people think?
>
> reST is no programming language,

I agree.

> i thought the text should be a valid document (as far as possible)
> otherwise we might need a text-writer.

Don't know what you mean by "we might need a text-writer".

> and the test of course must know if it is required or optional.

I think a test should fail if any aspect of a language isn't there.

>> Another question, from the to-do list: Should we use the language
>> module for directive option names?  In other words, should
>> directive option names be translated?

How about this one?  Right now in English we would write::

    .. contents:: :local:

In German, "contents" is translated, but "local" is not::

    .. inhalt:: :local:

So should directive options be translated too?

--=20
David Goodger  <go...@py...>  Open-source projects:
  - Python Docutils: http://docutils.sourceforge.net/
    (includes reStructuredText: http://docutils.sf.net/rst.html)
  - The Go Tools Project: http://gotools.sourceforge.net/