[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-doc
Subject:    Re: Semantic tags for i18n, official proposal
From:       Chusslove Illich <caslav.ilic () gmx ! net>
Date:       2007-06-19 14:34:24
Message-ID: 200706191634.26978.caslav.ilic () gmx ! net
[Download RAW message or body]


> [: Yukiko Bando :]
> No. I use different styles for text to checkboxes and text to
> radiobuttons. See my reply to Marek. :)

> Why not use @checkbox, @radiobutton and @combobox [...]

Uh-oh. This is the logical conclusion of the story, that I meant to point
towards in prevous messages, but thought let's not prejudice :)

It is entirely clear to me that the most helpful to translators would be if
just by looking at a single message, it would immediatelly be obvious what
is the position of the message in the UI, as if one were looking into the
running program. The needed contexts would then be more "graphic" rather
than "semantic", exactly like @checkbox, @radiobutton, etc. Especially the
incosistency is rarely good; the proper thing would then be to have also
@button, @messagebox, @menu, and so on, instead of the proposed semantic
contexts.

And I would have nothing against this, except that it seems to me too
excessive to be actually used. Also, than we're in trap of a no now-
considered graphical context being appropriate for some cases (and we'd
anyway need 15 or so of them), so that further expansions would be needed.
And to leave in semantic contexts too as fallback for these situations,
seems positively ugly to me.

Therefore I came with these few (well, still finger-countable :) semantic
contexts as a middle-of-the way solution, but hopefully still a lot better
than no contexts, and general enough to be able to accomodate uses that we
don't see now.

On the other hand, I am making these considerations entirely on my hunch. I
could be completely wrong. But how to tell? It's not like many programmers
have commented on this point, either arguing for or against. In fact you
were by far of most help in this department :)

So, with this middle-of-the way, a lot better than nothing, but somewhat
general, consistent and not overly voluminous, approach in mind, let's try
another example. One should also think about the PO file in general, so if
there is a sequence of messages:

  msgctxt "@title"
  msgid "Tab Key Mode if Nothing Selected"

  msgctxt "@option"
  msgid "Insert indent characters"

  msgctxt "@option"
  msgid "Insert tab character"

  msgctxt "@option"
  msgid "Indent current line"

  ...

  msgctxt "@title"
  msgid "Keys to Use"

  msgctxt "@option"
  msgid "Tab key indents"

  msgctxt "@option"
  msgid "Backspace key indents"

wouldn't it be enough to produce good translation? Yes, just by looking at
single @option message you cannot tell some things. But the connected @title
message would most of the time be nearby, and it seems to me it would shed
just enough light as if the more specific @radio and @checkbox context would
have been used for options.

In fact, am I wrong if I think that it is precisely the knowledge of which
@title corresponds to the @option that is the important bit for the
translation, judging by your reply to Marek's mail, rather than @checkbox/
@radio distinction?

-- 
Chusslove Illich (Часлав Илић)
Serbian KDE translation team

[Attachment #3 (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]