[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:       Yukiko Bando <ybando () k6 ! dion ! ne ! jp>
Date:       2007-06-19 22:58:09
Message-ID: 200706200805.45137.ybando () k6 ! dion ! ne ! jp
[Download RAW message or body]

Chusslove Illich wrote:
> > [: Yukiko Bando :]
> > Why not use @checkbox, @radiobutton and @combobox [...]
[...]
> 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.

OK.  I understand why you chose "semantic" instead of "graphic". 

How about looking at it this way then?

(action) @action
(title) @title
(label) @label
(option) @checkbox, @radiobutton, @combobox, @item
(info) @tooltip, @whatsthis, @process, @info

The five categories (between brackets) are based on semantics.
The option and the info are so diverse that they are split into 
subcategories (actual tags) to make translators life easy. :)    

> 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?

The tag @checkbox (and @combobox too) can tell translators that the 
message should be treated carefully i.e. it is part of a group of options 
and dependent on the preceding label.  On the other hand, @checkbox quite 
often doesn't require such close inspection of context and can be reused 
elsewhere more safely.    

I'm thinking of creating new dictionaries by context tags so I can reuse 
translated messages.  I want to exclude ambiguous @checkbox and @combobox 
from @option (checkbox).  So, if @radiobutton and @combobox are not 
acceptable as part of semantic tags, please at least don't mix them with 
@option (checkbox) and keep them among @item. :) 

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