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

List:       kde-i18n-doc
Subject:    Re: Semantic tags in KDE4
From:       Yukiko Bando <ybando () k6 ! dion ! ne ! jp>
Date:       2007-05-01 15:47:05
Message-ID: 200705020047.05274.ybando () k6 ! dion ! ne ! jp
[Download RAW message or body]

Chusslove Illich wrote:
> > [: Yukiko Bando :]
> > It would be even better for Japanese if options with a check box
> > (i.e. those which take a boolean value) can be distinguished.
> 
> I've intended the @option context to be these boolean values, but also
> those with numbers. Perhaps we should limit @option to strictly
> boolean, and relegate counters and sliders to general @info?

As you proposed later, I think @label would be better for counters and 
sliders.

> > I may ask too much but is it possible to separate tooltips from
> > What's this and quick help messages?
> 
> I also thought at first to have a @tooltip. But I don't think it's
> really a good context, as it's tied to visual representation. For
> example, both hovering text and What's this are presented as tooltips.
> 
> If I understood, you say that you would use a different grammar style
> for a hovering tooltip text, and What's this tooltip text?

AFAIK we don't have a strict rule, but hovering tooltips are often 
translated as a phrase, not as a complete sentence, probably to make them 
short.  In reality, however, the same message is often used for both 
tooltip and What's this help...  

> To me, one is just the expansion of the other.

You are right.  Maybe we should rethink about how to translate tooltips... 

> Though, I could imagine one solution to handle both this and previous
> situation: a @label context. @label could be text to sliders, counters,
> and hovering tooltips. Then @option would be just boolean (check
> box/radio button), and @info would be What's this and message boxes.

For the above reasons, I think @info is appropriate for tooltips.  Except 
that, I'm for this solution.   

> > I don't understand well here.  Do you mean that I will not need to
> > manipulate tags to avoid bold and italic?  How can menu items etc. be
> > displayed like「ターミナルを開く」(between Japanese quotes) in help \
> > messages then?
> 
> It would work like this. Instead of:
> 
> "...use the \"Configure Email\" button..."
> 
> programmer would use the <interface> tag:
> 
> "...use the <interface>Configure Email</interface> button..."
> 
> The <interface> tag is expanded into some form of markup (for rich text
> contexts, like @info) or quotes (for plain text contexts, like @shell),
> and translators can globaly set these expansions via messages in
> kdelibs.po:
> 
> # Translation of kdelibs.po to Japanese
> ...
> 
> #: localization/markup.cpp:111
> #. Visual tag format, blah, blah, see http://...
> msgctxt "interface/rich"
> msgid "<b>%1</b>"
> msgstr "「%1」"
> 
> #: localization/markup.cpp:112
> #. Visual tag format, blah, blah, see http://...
> msgctxt "interface/plain"
> msgid ""%1""
> msgstr "「%1」"
> 
> ...
> 
> #: kdeui/dialogs/kbugreport.cpp:138
> msgid ""
> "Your email address. If incorrect, use the "
> "<interface>Configure Email<interface> button to change it"
> msgstr ""
> "あなたのメールアドレスです。違っている� \
> �合は<interface>Eメールを設定</interface>" \
> "ボタンを使って変更してく� さい。"

Sounds great! :)  Thanks for the explanation.

Yukiko


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