[PATCH] Add long comments to shared-mime-info XML file

Andrew J. Montalenti ajm at pixelmonkey.org
Sat Oct 15 12:50:43 PDT 2005


Dear Christian,

On Sat, 2005-10-15 at 21:18 +0200, Christian Neumair wrote:
[...]
> I have three problems with your proposal:
> 
> a) Backwards compatibility. I know, we haven't reached 1.0 yet, and
> don't make semantic guarantees but it's plain unfriendly to introduce
> markup in a previously markup-free string which could be interpreted
> plain. GNOME 2.10 and 2.12 would display the abbr tag carbon, which is a
> no no.

I agree.  That is a problem.  In fact, it may just be big enough that
I'd be willing to take back my proposal.

[...]
> Having markup tags inside gettext strings is perceived as being very,
> very i18n unfriendly and confusing, especially since it involves string
> merging that is not obvious, at least not to the average translator, and
> will lead to dozens of problems. I'm quiet surprised that Behdad
> proposed the same, although I think he is involved into the Persian
> GNOME i18n.

I didn't think about il8n, but you're right, this would be a problem.

> c) I don't like the semantics. I think the <abbr/> tag isn't appropriate
> here, just because "HTML uses it". Its naming just isn't quiet right in
> this context, because "Windows Media Video" is not an abbreviation for
> "WMV video", but for "WMV", i.e. if you take <abbr/> serious
> semantically, it's meant to be used like
> 
> <_comment><abbr title="Windows Media Video">WMV</abbr> video</_comment>

How you wrote it here is actually exactly how I imagined it being used.

> and not like
> 
> <_comment><abbr="WMV video">Windows Media Video</abbr></_comment>

Yes, this would be silly--you may as well include "abbr" as an attribute
of the comment element.

> > But this way, later on, if GtkLabel's get some feature equivalent to
> > <abbr> tags, we'll be able to use them.
> 
> i18n people will kill you if you do run-time merging of marked up text,
> as mentioned above and below. Rather use the complete strings, and
> explicitly offer all possible combinations, i.e. use
> 
> if (abbr_html && abbr_css) {
>   string = g_strdup_printf (_("HTML and CSS"));
> } else if (abbr_html) {
>   string = g_strdup_printf (_("HTML and Cascading Style Sheets"));
> } else if (abbr_css) {
>   string = g_strdup_printf (_("Hyper Text Markup Language and CSS"));
> } else {
>   string = g_strdup_printf (_("Hyper Text Markup Language and Cascading
> Style Sheets"));
> }

Okay, I could see how this would be better.  Of course, from an il8n
POV, it seems to me this would multiply the number of total strings to
be translated by some factor and would result in a lot more work for
translators, all so we can just TWAIN expanded into its useless
acronym ;-) ...

[...]
> I'm sorry but because of b) I really have to insist on the unexpanded
> and the expanded version of a MIME description being two totally
> separate strings. I guarantee you that if we CCed gnome-i18n at gnome.org,
> many people supported my POV.

Okay, I agree with you.  How about we just clean up the redundancies in
the strings, unless someone comes up with a way to get the benefits of
my proposal without messing with b) in your criticism.

> I'm also very sorry for the long followup, things like this can usually
> better be discussed by two people using the phone. It's really a PITA to
> read and/or write long mails.

I agree.  Sorry I snipped your e-mail to death, but I wanted to make
mine at least readable! :-)

-Andrew




More information about the xdg mailing list