[gentoo-dev] [RFC] i18n project

[gentoo-dev] [RFC] i18n project

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 1730 bytes --]

So, as someone might have read in my blog[1] I've been thinking for a couple 
of days about creating an i18n project.

What would an i18n project be needed for? Mainly, to try to provide to our 
non-English native users a more friendly environment. We discussed many times 
in the past about making simpler having UTF-8 support, or even enabling it by 
default, but of course it's difficult to handle this right now, and this is 
not the only concern.

What I have in mind is establishing some kind of team that would collaborate 
with the current doc translators that would like to help, trying to get other 
parts of Gentoo accessible to non-English speakers. Translating man pages for 
Gentoo-specific software, making Portage and other gentoo-specific packages 
i18n-capable and translating them, translating forums (I think the Forums 
stuff already handle that, but maybe it would help if we're able to get a 
more "complete" team).

Least but not last, also translating software that's missing translator, like 
I did for xine-lib/xine-ui/gxine and Italian this week, or at least 
release "poupdate" tarballs with translations updated from CVS when the ones 
in the releases are obsolete.

This might also help to find a "home" to utf8 and cjk herds, for instance.

I'm actually going to work to add to Portage (will-be-2.2) i18n capabilities 
next week, and I'll be doing for sure the Italian translation.

Comments, thoughts, translation, are all welcome :)

[1] 
http://farragut.flameeyes.is-a-geek.org/articles/2006/06/08/do-we-need-an-i18n-project
-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [RFC] i18n project

[Jan Kundrát]

[-- Attachment #1: Type: text/plain, Size: 1161 bytes --]

So, let's rephrase it a bit. The following items represent my view about
the i18n team's responsibilities:

a) Translation of metadata.xml stuff in our tree (Is there any method to
keep them up-to-date when the English text changes? Something like
"revision" attribute that gets bumped when the English text gets updated?)

b) Localization of Gentoo-developed applications (portage,
gentoolkit,...) including their manpages

c) l10n for other packages and sending patches upstream

d) Translation of manpages. man-pages-cs for example sucks :(.

e) Persuading people that having comments in configuration files
*without* an equivalent somewhere on the web is evil. Good example might
be baselayout. Why? Stuff on the web can be translated pretty easily,
configuration files can't.

e) Translation of our documentation (that's the GDP's job, the intention
is just to "share human resources" :) ) and GWN.

f) Translation/localization of w.g.o. Efforts were already started
(meaning that "the technology is available on at least one experimental
site).

My 0.02 Kč :)

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

Re: [gentoo-dev] [RFC] i18n project

[Marius Mauch]

[-- Attachment #1: Type: text/plain, Size: 3345 bytes --]

On Sat, 10 Jun 2006 15:11:50 +0200
Jan Kundrát <jkt@gentoo.org> wrote:

> b) Localization of Gentoo-developed applications (portage,
> gentoolkit,...) including their manpages

I don't really like this one. Documentation, sure, but for the tools
themselves I think it could cause more problems than actually help.
Quoting a relevant discussion from #gentoo-portage earlier today that
hopefully explains my concerns:

<zmedico> I think if we are going to override LC_MESSAGES then we
should consider it in terms of broader gettext support in portage.
<zmedico> Flameeyes wants to help internationalize portage... 
<SpanKY> not much point if we reset language variables 
<zmedico> yeah, it has to be considered together 
<genone> zmedico: I don't like that idea much 
<zmedico> reasoning?
<genone> makes support harder
<genstef> extending the problem we are trying to solve, yeah
<zmedico> we can refuse to support non-english reports.
<zmedico> we already to afaik
<zmedico> s/to/do/
<genone> I'm not only talking about bugzilla
<genstef> haahaa, why do we have it in portage then?
<genstef> how can something be both "official" and "unsupported"? ;)
* genstef is stealing arguments from his opponents on the mailing
lists ;) 
<zmedico> genone: if not bugzilla, then...?
<genstef> forums, irc, mailing lists
<genone> zmedico: any support channels: bugzilla, forums, irc, ...
<genstef> direct mail
<genone> not only support by us, but also user2user
<solar> lots of things are officially unsupported
<zmedico> I was thinking we could have a mode that gives both english
and the user's native locale 
<solar> like overlays should of been one of those. overlay.dev.gentoo
vs overlays.gentoo 
<genone> zmedico: two tracebacks? ;)
* zmedico nods
<zmedico> 2 exception strings
<genstef> so portage exit errors will be doubled?
<genone> IMO english+native is a extremely crappy thing
<zmedico> yeah, maybe :)
<zmedico> the thing is, nobody forces you to look at forums, irc, mail
that's in a foreign language 
<genone> and my point is that users often don't even realize that their
post contains non-english text 
<zmedico> it's an breach of etiquette, and they should be chastized :)
<zmedico> I'd hope it could be handled well enough at a social level
<genone> also in my experience translations in FOSS tend to be of poor
quality, there have been several situations where I didn't understand
what the german translation was supposed to mean where the original was
perfectly clear 
<genone> "Overtranslation" being one big problem
<zmedico> that's a problem for the maintainers of the translations.
portage devs won't handle translation... 
<genone> well, maybe I'm wrong, but I think it would cause more
problems than help 
<zmedico> too bad not everyone knows english. :)
<lisa> too bad not everyone knows norwegian. :)

Basically I don't think the benefit is rather dubious or maybe it's
just that I had some rather bad experiences with translated versions of
FOSS applications, but I'm quite opposed to this part of the project
unless you have a way to remove my concerns.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [RFC] i18n project

[Peter Volkov (pva)]

[-- Attachment #1: Type: text/plain, Size: 1092 bytes --]

On Вск, 2006-06-11 at 02:16 +0200, Marius Mauch wrote:
> On Sat, 10 Jun 2006 15:11:50 +0200
> Jan Kundrát <jkt@gentoo.org> wrote:
> > b) Localization of Gentoo-developed applications (portage,
> > gentoolkit,...) including their manpages
> 
> I don't really like this one. Documentation, sure, but for the tools
> themselves I think it could cause more problems than actually help.

IIUYC there are tree problems with localized portage tools: 1) for users
such bug reports are hard to search 2) for devs it's hard to read
localized bug reports 3) "Overtranslation" for all it's hard to
understand. Right?

1,2): While generally I agree that output of build process should be in
"C" locale at least the following line should be translated on all
possible languages:
!!! If you need support, post the topmost build error, and the call
stack if relevant.

Everybody will benefit from translation of this message. ;)

3) Bad translation is "just another bug" that should be fixed. Nothing
in reality can be done without errors. But have this stoped anybody?

Peter.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-dev] [RFC] i18n project

[Jan Kundrát]

[-- Attachment #1: Type: text/plain, Size: 875 bytes --]

Marius Mauch wrote:
> <genone> and my point is that users often don't even realize that
> their post contains non-english text

Make Portage add a line with "Some of the previous errors were reported
in non-English language. If you want to get support from official
channel, please run `LC_ALL=C command`." when it detects a non-English
locale.

> Basically I don't think the benefit is rather dubious or maybe it's
> just that I had some rather bad experiences with translated versions of
> FOSS applications, but I'm quite opposed to this part of the project
> unless you have a way to remove my concerns.

Sure, translating GCC output is *not* good, but why don't provide
localized version of Portage messages like, for example, those when
Portage complains about unsatisfied dependency?

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

Re: [gentoo-dev] [RFC] i18n project

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 452 bytes --]

On Sunday 11 June 2006 13:08, Jan Kundrát wrote:
> Sure, translating GCC output is *not* good, but why don't provide
> localized version of Portage messages like, for example, those when
> Portage complains about unsatisfied dependency?

What about messages output by ebuilds? Are they also going to be 
translated? In that case, how?

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] [RFC] i18n project

[Jan Kundrát]

[-- Attachment #1: Type: text/plain, Size: 317 bytes --]

Paul de Vrieze wrote:
> What about messages output by ebuilds? Are they also going to be 
> translated? In that case, how?

There's no way to provide localized output of einfo/... calls from
ebuild that I'm aware of. Suggestions are welcome :)

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

Re: [gentoo-dev] [RFC] i18n project

[Flammie Pirinen]

[-- Attachment #1: Type: text/plain, Size: 804 bytes --]

2006-06-19, Jan Kundrát sanoi, jotta:

> Paul de Vrieze wrote:
> > What about messages output by ebuilds? Are they also going to be 
> > translated? In that case, how?
> 
> There's no way to provide localized output of einfo/... calls from
> ebuild that I'm aware of. Suggestions are welcome :)

Is there a reason why calling gettext from einfo() etc. or extracting
messages from tree using e.g. xgettext wouldn’t work?

Apart from technicalities, it does raise number of practical problems
to keep translations up-to-date with live tree as well as making the
messages easier to localise, as with current spliced strings it would
generally be a PITA to do.

-- 
Flammie, Gentoo Linux Documentation’s Finnish head translator
and FlameEyes’ bot <http://dev.gentoo.org/~flammie>.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-dev] [RFC] i18n project

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 728 bytes --]

On Monday 19 June 2006 13:16, Flammie Pirinen wrote:
> 2006-06-19, Jan Kundrát sanoi, jotta:
> > Paul de Vrieze wrote:
> > > What about messages output by ebuilds? Are they also going to be
> > > translated? In that case, how?
> >
> > There's no way to provide localized output of einfo/... calls from
> > ebuild that I'm aware of. Suggestions are welcome :)
>
> Is there a reason why calling gettext from einfo() etc. or extracting
> messages from tree using e.g. xgettext wouldn’t work?

this would make it impossible to translate strings when einfo is given 
user-based variables (die "econf $* failed")

just use bash's system for translating strings:
echo $"hihihihi"
einfo $"PLEASE TO READ ME"
-mike

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] [RFC] i18n project

[Peter Volkov (pva)]

[-- Attachment #1: Type: text/plain, Size: 2149 bytes --]

On Сбт, 2006-06-10 at 15:11 +0200, Jan Kundrát wrote:
> a) Translation of metadata.xml stuff in our tree (Is there any method to
> keep them up-to-date when the English text changes? Something like
> "revision" attribute that gets bumped when the English text gets updated?)

While we do not have "version" or "revision" attribute, just drop all
translations whenever you update English.

> c) l10n for other packages and sending patches upstream
> d) Translation of manpages. man-pages-cs for example sucks :(.

Do we really need to do this inside Gentoo i18n project? This tasks are
common for many distributions and should be done outside Gentoo. So just
translate and send translations upstream.

> e) Translation of our documentation (that's the GDP's job, the intention
> is just to "share human resources" :) ) and GWN.
> 
> f) Translation/localization of w.g.o. Efforts were already started
> (meaning that "the technology is available on at least one experimental
> site).

Opposed to c) and d) this requires organization inside Gentoo and thus
requires i18n project. Fex, to increase the profit from translated GWN
translated versions should come out together with English one.

> e) Persuading people that having comments in configuration files
> *without* an equivalent somewhere on the web is evil. Good example might
> be baselayout. Why? Stuff on the web can be translated pretty easily,
> configuration files can't.

Personally I do not like idea to look at web for package documentation.
There already exist decision to put all example files somewhere
into /usr/share. I hope one day this happens and then all translated
configuration files also can be put there.

I think the main goal of i18n should be not translation but organization
(at least at first time). Untranslated staff will always remain because
devs have lack of time/interest and project can nothing to do with that.
But people post bugs with translated metadata, translated documentation
and to resolve them we need place to find the right devs for this. And
i18n project is the right place to look for them.

Peter.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-dev] [RFC] i18n project

[Jan Kundrát]

[-- Attachment #1: Type: text/plain, Size: 1890 bytes --]

Peter Volkov (pva) wrote:
> On Сбт, 2006-06-10 at 15:11 +0200, Jan Kundrát wrote:
>> a) Translation of metadata.xml stuff in our tree (Is there any method to
>> keep them up-to-date when the English text changes? Something like
>> "revision" attribute that gets bumped when the English text gets updated?)
> 
> While we do not have "version" or "revision" attribute, just drop all
> translations whenever you update English.

Re-adding them again and checking RCS history seems like unnecessary
work to me.

>> c) l10n for other packages and sending patches upstream
>> d) Translation of manpages. man-pages-cs for example sucks :(.
> 
> Do we really need to do this inside Gentoo i18n project? This tasks are
> common for many distributions and should be done outside Gentoo. So just
> translate and send translations upstream.

Nope, that wouldn't be the primary job of the i18n team, just some kind
of task that they might do when they'd be idling otherwise :)

> Fex, to increase the profit from translated GWN
> translated versions should come out together with English one.

Tricky or even impossible one, considering the current time schedule.

> Personally I do not like idea to look at web for package documentation.
> There already exist decision to put all example files somewhere
> into /usr/share. I hope one day this happens and then all translated
> configuration files also can be put there.

While the comments in configuration files are certainly very useful, I
am persuaded that they shouldn't contain more information than the docs
available somewhere else. It's quite common for an administrator to work
on a remote box, possibly with a crappy network connection, and browsing
some doc over web is easier than launching yet another links session
under screen.

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

Re: [gentoo-dev] [RFC] i18n project

[Nguyễn Thái Ngọc Duy]

On 6/10/06, Jan Kundrát <jkt@gentoo.org> wrote:
> So, let's rephrase it a bit. The following items represent my view about
> the i18n team's responsibilities:
>
> a) Translation of metadata.xml stuff in our tree (Is there any method to
> keep them up-to-date when the English text changes? Something like
> "revision" attribute that gets bumped when the English text gets updated?)
Keep only English in metadata.xml. Using tools such as intltool or
xml2po to extract strings and let i18n translate/maintain .po files
themselves. Generated .mo files will be included in metadata directory
when rsycing. Another portage hack to use .mo files in metadata
directory instead of plain English if locale variables is not C.

But that's just part of the problem. What about strings inside ebuild?
-- 
Bi Cờ Lao

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] i18n project

[Jan Kundrát]

[-- Attachment #1: Type: text/plain, Size: 569 bytes --]

Nguyễn Thái Ngọc Duy wrote:
> Keep only English in metadata.xml. Using tools such as intltool or
> xml2po to extract strings and let i18n translate/maintain .po files
> themselves. Generated .mo files will be included in metadata directory
> when rsycing. Another portage hack to use .mo files in metadata
> directory instead of plain English if locale variables is not C.

That would require external tools to support Yet Another Method of
Retrieving Metadata which is a Bad Thing (tm).

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

Re: [gentoo-dev] [RFC] i18n project

[Flammie Pirinen]

[-- Attachment #1: Type: text/plain, Size: 1169 bytes --]

2006-06-10, Diego 'Flameeyes' Pettenò sanoi, jotta:

> I'm actually going to work to add to Portage (will-be-2.2) i18n
> capabilities next week, and I'll be doing for sure the Italian
> translation.

Would this be a fix to Portage NLS bug
<http://bugs.gentoo.org/show_bug.cgi?id=13618>? If so, have you
considered what I have said in the bug? If the translation possibility
is going to concern the static Portage messages only, I fear that it
will be slight waste of time. Users will generally find partial
translations more harmful than no translations at all, and in Portage's
case I think that the ebuild/eclass messages will often contain the more
important parts of information, which will surely cause more annoyance
than be useful. Imagine that for fetch restrictions, you get first
generic note about fetch restriction in your native language, then n+1
lines of lengthy information how to fetch in English, not nice.
Similarly for post package install instructions, or conflicting USE
flag instructions etc. etc.

-- 
Flammie, Gentoo Linux Documentation’s Finnish head translator
and FlameEyes’ bot <http://dev.gentoo.org/~flammie>.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 191 bytes --]