Re: Markup in messages

On 7/25/06, Abel Cheung <abelcheung gmail com> wrote:
On 7/18/06, Christian Rose <menthos gnome org> wrote:
> Behdad, this is about
> -- it was only recently that I discovered that you have included a
> section about markup to :
> "Following is a list of examples that need to be marked for
> translation, but were not in some cases:
> [...]
> '<b>%s</b>': That is an innocent way to mark something to make it
> boldface in the interface, to emphasize importance or make it a
> header. But not every language has a concept of modern boldface
> typefaces, or even if it has such fonts, they may not be the preferred
> font for such kind of emphasis."
> So are you suggesting that developers include the surrounding markup
> in the translateable message, in case you may need to change it for
> Persian for rendering purposes?

My guess is that they are just reluctant to changing anything
not visually beneficial, not that they have already foreseen
the problem. But to make an excuse, this is a good
one, especially when what Behdad said is valid. I have been
bitten by this kind of markup/font issues myself.

Due to absense of freely available boldface Chinese font, I
have seen somebody translate things like:

msgid "<b>%s</b>"
msgstr "<i>%s</i>"

in order to distinguish it from normal text.

Of course in most cases the proper 'fix' is to have a boldtype
font. But creating a boldface font is not always that easy,
when one is talking about complex scripts that consists of
at least hundreds or thousands of glyphs; and it needs quite
some human horsepower as well, which may not be available for
newly available languages in F/OSS world.

I understand that problem, but I for sure don't agree that this is the
proper way to fix it, as this hack, that is, gratiously including
surrounding markup inside the translateable message content, causes a
lot of problems for all translators. As a translator you want to
translate the *content*, not the surrounding presentation. I don't
care whether the words will be written on a billboard, a folder, or
on-screen, the words will be the same. As Clytie explained:

I support you. Not only is it a problem, one more thing that can
break, but it's one more difference preventing exact matches using

I spend way too much time changing fuzzy strings like this:

msgid "<b>Preferences</b>"
msgstr "Tùy thích"


msgid "<b>Preferences</b>"
msgstr "<b>Tùy thích</b>"

simply adding, modifying or removing formatting to match the original
string. The actual text is fine.

I really don't see it as our job to adjust formatting. I would indeed
prefer to concentrate on the actual translation.

Here are some ways to solve the problem of bad rendering:

1) Fix the fonts. Agreed, not an easy task.

2) Solve the problem at the Pango level. Instead of encouraging the
use of <b> and <i> tags, add abstract <strong>, <em> tags/attributes
or some such, allowing for different interpretations for different
scripts. If we know that boldface fonts for Persian always suck,
<strong> can have a different representation for Persian script.
Then the HIG and other such specifications can specify these
attributes instead of a particular font style.

And here's how to solve the (ab)use of using surrounding PangoMarkup
inside translateable messages:

3) Make gtk+/Pango have support for *attributes* instead of forcing
everyone to use PangoMarkup. If I want a label to be bold, italic,
smaller, or larger, I as a developer should be able to simply set
attributes to that effect. Right now, it's too common to see something
like this:

msgid "<span size=\"xx-large\">Bug Buddy</span>"
msgstr "<span size=\"xx-large\">Bug Buddy</span>"

msgid "<span weight=\"bold\">Date & Time</span>"
msgstr "<span weight=\"bold\">Datum och tid</span>"

msgid "<b>Date & Time</b>"
msgstr "<b>Datum och tid</b>"

msgid "<span size=\"medium\"><b>No file</b></span>"
msgstr "<span size=\"medium\"><b>Ingen fil</b></span>"

msgid "No file"
msgstr "Ingen fil"

Often, you will have duplicated messages in the same file, just with
different markup!

If gtk+/Pango and libglade would make it possible for application
writers to set *attributes* for these things instead of having to
resort to PangoMarkup, all problems would be solved.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]