Le mardi 26 juin 2007 à 12:53 -0400, Warren Togami a écrit :

Nicolas Mailhot wrote:

...

Le Lun 25 juin 2007 10:09, Jens Petersen a écrit :

...

We are thinking that it would be a good to have a meeting of the Fedora I18n project to discuss various technical issues openly.

Some of the things to discuss include:

• installation package defaults
• input method desktop defaults and configuration (xinput/im-chooser)
• renaming of fonts-* to reflect upstream projects
• adding a IM package group?

I'd like to attend, but probably only could in the evening (western european time). I'd like the following topics discussed:

• extented (multimedia) key Fedora target (wait-and-see, active Fedora

push, to evdev or not to evdev?)

• font policy/comps i18n group organisation -> some fonts bring

support for scripts used by existing desktop locales, others for scripts associated to langages we don't have localisation for (tiffinagh, n'ko, inuktikut, tibetan?), others are purely decorative and no one will use them in real life by default, others are for historical scripts (dead languages, medieval variants, old greek, church scripts...). How all this stuff is supposed to be organised in comps? How will it appear in anaconda/yum guis?

These are legitimate issues, but we need to limit the scope of this meeting if we are going to tackle the highest priority problems before F8.

Well, I do i18n fonts, so I sort of need to know where I fit in :)

and to evdev or not is linked to IM anyway.

...

• what to do when upstream is dormant or end-user unfriendly? Where

and how should user feedback be directed? Do we need a Fedora-level i18n technical hub? Do we have the resources for it? (hunspell dicts, xkb maps, console maps, abandonware fonts, etc)

This is an issue that effects more than just i18n, perhaps FESCo should discuss and create general policy instead?

It's a general issue, but it's much worse for i18n. Good i18n absolutely requires locals to report problems, and the people most likely to do the best reports are also the most likely to be put of by the technical english interfaces technical testers use.

Also some resources like fonts and dicts have pretty much the worst possible upstreams on the maintenance scale (having OO.o as dict source is a joke, OO.o does not have the resources to support dicts and some of them are not even bundled with OO.o due to licensing clashes)

Le Jeu 28 juin 2007 08:22, Jens Petersen a écrit :

Nicolas Mailhot さんは書きました:

...

I'd like to attend,

Great!

...

but probably only could in the evening (western european time).

OK, that is a bit hard from Asia/Pacific where the Red Hat i18n team is located.

I know, my people are in Australia right now.

We will post logs anyway so you want also followup with comments by email of course. :)

Ok.

...

• extented (multimedia) key Fedora target (wait-and-see, active

Fedora push, to evdev or not to evdev?)

Not quite sure how this relates to i18n. Are you proposing to use it for international input or something?

Fixing Fedora input needs switching to evdev someday. It's very likely this switch will unearth bugs in the handling of international keyboards, as most evdev testers probably only use western keyboards (probably not too difficult to fix stuff, but i18n should be ready for the switch)

...

• what to do when upstream is dormant or end-user unfriendly? Where

and how should user feedback be directed? Do we need a Fedora-level i18n technical hub? Do we have the resources for it? (hunspell dicts, xkb maps, console maps, abandonware fonts, etc)

Ok. Some of these may be case-by-case. Let's discuss when you can join.

Unfortunately while some cases are extremes you have a general pattern of i18n not getting sufficient feedback because of langage barriers. At best you have translation teams but i18n is far more than translation. People (esp. people new to Linux) just assume things are broken by default and there's nothing to be done (You learn there are problems when you go to local forums and someone rants about Fedora i18n problems, but you never get the problem reports directly)

That's why other distros have i18n hubs with a strong presence and activity. It's dishearting to notice time and time again other distros manage to get problem reports for stuff which was pushed in Fedora months before without anyone reacting.

Le Jeu 28 juin 2007 10:42, Jens Petersen a écrit :

Nicolas Mailhot さんは書きました:

...

...

...

• extented (multimedia) key Fedora target (wait-and-see, active

Fedora push, to evdev or not to evdev?)

Not quite sure how this relates to i18n. Are you proposing to use it for international input or something?

Fixing Fedora input needs switching to evdev someday. It's very likely this switch will unearth bugs in the handling of international keyboards, as most evdev testers probably only use western keyboards (probably not too difficult to fix stuff, but i18n should be ready for the switch)

Ok, I would like to know more - some pointers would be useful. Is it closer to kernel kbd handling?

evdev cuts out some translation layers between X and the kernel. So you're less likely to have different bugsets in the kernel and X, and switching to evdev will just kill lots of legacy limitations/bugs.

However evdev has not got the test coverage of the currend X kbd driver, so bugs can still be lurking.

O/H Ryo Dairiki έγραψε:

Jens Petersen wrote:

...

We are thinking that it would be a good to have a meeting of the Fedora I18n project to discuss various technical issues openly.

I'm interested in participating as well.

I would like to join this. I have some topic to discuss there:

• Localized official information for End Users
  • Actually, there is a Japanese Fedora Community called "Fedora JP",

but this seems to be dying. - End Users need Up-to-date official information in their own language. - Translation of official documents is not enough, but language specific information is also needed.

Localization is handled by the Fedora Localization Project. The project has many teams handling transaltions and localization in general, many of which have their own website, mailing list etc. More info at:

http://fedoraproject.org/wiki/L10N

I believe that bringing the topics about translations, language-specific information, and local communities on the FLP mailing list will result in feedback from a lot of people having similar concerns. IMO, this would apply for most of the (very interesting) topics below. :-)

• Localized configurations, and language specific packages
  • Font configuration for Java.
  • Japanese specific tex sub packages.
  • Language specific packages should be firstly reviewed by local

people. (Not directly sent to FE)

• Translation infrastructure like bugzilla.
• Localized bugzilla
• Localization QA

[...]

...

If you are interested in joining this discussion please reply and let us know when you would prefer the meetings and also any potential agenda items. Obviously it is going to be hard to find a time that is good for everyone all the time so we might try alternating between morning and evening in East Asia to give people in other regions some chance to participate also.

I would like to have the first meeting in #fedora-i18n on Freenode this week.

Maybe we should do it in #fedora-meeting? See:

http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel

-d

Ryo Dairiki さんは書きました:

- Font configuration for Java.

We hope the situation will improve with openjdk. Do you have some ideas how to improve font configs for current java binaries packages?

- Japanese specific tex sub packages.

I think they could probably go into Fedora if someone is willing to package them. What is the current status of Japanese TeX projects. Is pTeX still actively maintained?

- Language specific packages should be firstly reviewed by local 

people.

Yes if it helps to have Japanese speakers to do initial (pre)reviews then I think it is a good idea if it encourages people to submit packages, but the final reviews still need to be done in English in bugzilla.

• Localized bugzilla

It would be good to have bugzilla translated probably, but I don't know of any plans for that.

- Collecting information in local languages. (Not only bugs, but 

also desires) - Later send translated bug-reports or patches to upstream. - Maybe, translator should be assigned for each bug report then.

I don't think we have enough resources to do that in bugzilla.redhat.com or within the main fedora project but if some "ambassadors" or mediators can help with this it would be useful I think. They would need to have a good working understanding of both sides.

• Localization QA
  • QA members for every language, mainly for input methods.
  • QA members may send their reports to localized bugzilla to prevent

regression.

This is a really important issue IMHO: how to improve i18n quality in fedora and how to work with Fedora QA on this. We should open some dialogue with the QA team on this I would say and make some plans for i18n QA.

Thanks, Jens

Le Mar 3 juillet 2007 04:49, Jens Petersen a écrit :

Ryo Dairiki さんは書きました:

...

- Font configuration for Java.

We hope the situation will improve with openjdk. Do you have some ideas how to improve font configs for current java binaries packages?

Kill the legacy core fonts java property file, use a fontconfig java font backup that will inherit all the i18n work done system-wide

There's so many ways to shoot oneself in the foot trying to fix the core font tables vendors ship with jvms it's no use even trying.

...

• Language specific packages should be firstly reviewed by local

people.

For many packages the problems are not first or post reviews but local reviews at all. The local groups need to engage with the distro packagers more.