[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-18 16:30:39
Message-ID: 200706190130.39645.ybando () k6 ! dion ! ne ! jp
[Download RAW message or body]

Chusslove Illich wrote:
> I have almost fully implemented the semantic markup for use in i18n
> messages, the KUIT (KDE UI Text), and it stands ready to commit. As
> base for comments, here is the article on Techbase:
>
> http://techbase.kde.org/Development/Tutorials/Localization/i18n_Semanti
>cs

Thank you for your work!

> What should the tag names look like? I've based them loosely on the
> Docbook, but they are not the Docbook. Especially I wanted to avoid any
> similarity with HTML, both for technical reasons (for the parser to
> differ them if combined) and for distinctiveness to programmers and
> translators.

It's not about naming but I have a question and a wish (again). :) 

@shell is not listed on the page.  Which tag will be assigned to command 
line options?
 
@info 
Any general body of text for user's information. These are texts to 
message boxes, tooltips and whatsthis entries.

I've seen some messages have "What's this text" or "Tooltip for ..." in 
msgctxt.  It's very helpful.  Would it cause any problems, either for 
programmers or translators, to split @info into @whatsthis, @tooltip and 
@info (for other messages)?  I don't understand source codes at all but 
have the whole /trunk/KDE/ only to see if a message is a tooltip or a 
whatsthis.  Sorry for bringing this up again but I still can't give up.

@process 
Similar to @info, but more specific in that the strings are messages 
output by an ongoing process. For example, "Copying files..." in 
file-copy progress dialog, or "Computing checksum..." in CD burning 
application.

This is a very nice addition. :)

> What other text modifications can you think of (like native separators
> in filepaths, or shortcut key separators)?

<note> 
The sentence is a side note of significance to the topic. 
Do not explicitly add "Note:", it will be formatted automatically. 

We translate "note" in different ways depending on whether a message is 
positive (e.g. hints, tips) or negative (e.g. restrictions).  Can we omit 
to translate "Note:" in kdelibs.po or omit the tag in individual 
messages? It's the same with "warning".  We may use two different words 
depending on its severity.

> What should be the policy of using KUIT for new applications? Advise it
> strongly, just would-be-nice, or at-your-discretion?

Advise it strongly.

> What should be the policy of using KUIT in existing applications?
> Encourage programmers to update the messages as they see fit? To only
> to use KUIT in new messages and those which are changed due to some
> other reason? Or not to use it all?

Encourage, if programmers have that time. :)  

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

Configure | About | News | Add a list | Sponsored by KoreLogic