FC2 release

[Jef Spaleta]

Gotta make sure gnucash is working though. ;)

crap...I hate you...you've totally made it impossible for me to get work
done today. I have a mounting FC2 todo list in my head now because of
you. It's worse than when i had rico suave stuck in my head for a week.

One thing i REALLY want to see as early as possible is to get the people
with accessibility concerns talking ASAP about a priority list of
concerns they want to see addressed in the next distro. Being blindsided
late in the last beta about lilo vs grub accessibility was totally
uncool.

And I'm not saying the next release is going to a magical silver bullet
to solve accessibility problems...its a hard problem..and its one very
prone for communication disconnects, even though technical/development
people recognize it is important. I think a roadmap to on "focused"
accessibility cleanup longterm is something worth working on. Just
trying to have every package maintainer try to deal with accessibility
issues as they come up..is going to suck for everyone. But if there were
some priorities so people who understand accessibility issues could
start somewhere and work with a few developers at a time...and march
through the distro so that 3 or 4 releases from now not only is
accessibility a lot cleaner but there will be a real human development
process in place to keep accessibility from being something each
maintainer has to try to remember to deal with.

I want to see an accessibility focus/support group to be there in the
community to help developers deal with issues. And i want that
focus/support group to have a long term vision and a master plan to get
from here to there.

-jef"i also want my own jet pack"spaleta

[seth vidal]

Post by Jef Spaleta

Gotta make sure gnucash is working though. ;)

crap...I hate you...you've totally made it impossible for me to get work
done today. I have a mounting FC2 todo list in my head now because of
you. It's worse than when i had rico suave stuck in my head for a week.

I could hum a few bars of 'ring of fire' if that would help at all ;)

Post by Jef Spaleta
One thing i REALLY want to see as early as possible is to get the people
with accessibility concerns talking ASAP about a priority list of
concerns they want to see addressed in the next distro. Being blindsided
late in the last beta about lilo vs grub accessibility was totally
uncool.

Do we have a tracker bug open for a11y issues that are open in bugzilla?
If not - one would be handy.

Post by Jef Spaleta
I want to see an accessibility focus/support group to be there in the
community to help developers deal with issues. And i want that
focus/support group to have a long term vision and a master plan to get
from here to there.

I think the a11y people who hammered on gnome might even be welcome.

-sv

ps: I'm still gonna harp on:

beta1 - valentine's day
beta2 - st patrick's day
freeze - april fool's day (so suitable)
release - US tax day-eve

or if 3 betas are better:

beta1 - Hot and Spicy Food International Day and National Nothing Day
(jan 16)
beta2 - valentine's day - feb 14
beta3 - st patrick's day - Mar 17
freeze - april fool's day - apr 1
release - US tax day-eve - apr 14

[Pedro Morais]

Post by Jef Spaleta
One thing i REALLY want to see as early as possible is to get the people
with accessibility concerns talking ASAP about a priority list of
concerns they want to see addressed in the next distro. Being blindsided
late in the last beta about lilo vs grub accessibility was totally
uncool.

Another "acessibility" issue is internationalization; the current process
isn't bad at all, but could be improved.
I was unfortunately very busy during this beta period (only managed to follow
the mailling lists and update portuguese translations), so I can't really
complain, but I kept i18n stats at 100% at almost all tims, and certainly at
the freeze point I'm sure that only the anaconda docs has a couple of
untranlated, and still there are powerdown messages in english (in the middle
of portuguese messages, so it's not a "too late for i18n issue") and, even
worse, up2date/rhn_register is half translated/half in english.

Clearly there's room for improvement.

[Paul Gampe]

Red Hat's internal localization team still has a considerable backlog of work
related to the Enterprise Linux 3 launch. We are hoping by mid-December to
be able to get back on track with the Fedora releases.

We are very excited by the strong support of community translators though, and
hope to have the time soon to be able to better coordinate these efforts.

Paul

Post by Pedro Morais
Another "acessibility" issue is internationalization; the current process
isn't bad at all, but could be improved.
I was unfortunately very busy during this beta period (only managed to
follow the mailling lists and update portuguese translations), so I can't
really complain, but I kept i18n stats at 100% at almost all tims, and
certainly at the freeze point I'm sure that only the anaconda docs has a
couple of untranlated, and still there are powerdown messages in english
(in the middle of portuguese messages, so it's not a "too late for i18n
issue") and, even worse, up2date/rhn_register is half translated/half in
english.
Clearly there's room for improvement.

[Alan Cox]

Post by Paul Gampe
related to the Enterprise Linux 3 launch. We are hoping by mid-December to
be able to get back on track with the Fedora releases.
We are very excited by the strong support of community translators though, and
hope to have the time soon to be able to better coordinate these efforts.

Does that mean that by mid December we can be thinking about getting the
lost translations (for non install stuff) rolling out as or with errata,
since Fedora doesn't have the errata restrictions RHEL does ?

[Pedro Morais]

Post by Alan Cox

Post by Paul Gampe
related to the Enterprise Linux 3 launch. We are hoping by mid-December
to be able to get back on track with the Fedora releases.
We are very excited by the strong support of community translators
though, and hope to have the time soon to be able to better coordinate
these efforts.

Does that mean that by mid December we can be thinking about getting the
lost translations (for non install stuff) rolling out as or with errata,
since Fedora doesn't have the errata restrictions RHEL does ?

That would be very good; each untranslated string is a serious acessibility
issue -- at least here in Portugal in the special market I use Linux
(industrial shop floor segment).
Although I do understand that's it's probably a lot of work for Red Hat to do
so, so maybe we better just think of ways to make sure there aren't any "lost
translations" on FC2.

[Paul Gampe]

Post by Alan Cox
Does that mean that by mid December we can be thinking about getting the
lost translations (for non install stuff) rolling out as or with errata,
since Fedora doesn't have the errata restrictions RHEL does ?

I may not be interpreting the question correctly Alan sorry, so do you mean
translations that have been committed for redhat-config-* but not picked up
in the rpm for the application?

I think Pedro's suggestion of specifying a date for package maintainers to
update their package is a reasonable solution, but I too have concerns about
the workload this would generate. Using cvs watch on the po/* files has been
an effective way for me to track as translations get updated, so that is one
way to know whether a rebuild is required.

Paul

[Alan Cox]

Post by Paul Gampe

Post by Alan Cox
Does that mean that by mid December we can be thinking about getting the
lost translations (for non install stuff) rolling out as or with errata,
since Fedora doesn't have the errata restrictions RHEL does ?

I may not be interpreting the question correctly Alan sorry, so do you mean
translations that have been committed for redhat-config-* but not picked up
in the rpm for the application?

There are some translations that are missing (not many AFAIK) and also a
pile of translation errata and updates that could go out with package
errata as they are done.

[Alan Cox]

Post by Paul Gampe
I may not be interpreting the question correctly Alan sorry, so do you mean
translations that have been committed for redhat-config-* but not picked up
in the rpm for the application?

The other category that needs addressing is stuff which is horribly
visible and down to a complete mess having been made during Fedora 1.
However it happened doesn't really matter now but one errata urgently
needed is redhat-menus because people fixed languages during Fedora beta 1
moaned they hadn't been updated in beta 2 and again in beta 3 and they
are still missing in FC1, making the most critical part of the entire desktop
English in those languages.

It completely ruins the internationalisation when the root menu translations
are still missing.

That would be a *great* starting point for fixing the i18n problems in
Fedora IMHO.

Alan

[Paul Gampe]

I have added myself to the bugzilla ticket you have on this, and will see if
we can assist the package maintainer in resolving this.

Following Jeremy's suggestion I have also added the i18n keyword to this bug.

Thanks Alan,
Paul

Post by Alan Cox
It completely ruins the internationalisation when the root menu
translations are still missing.
That would be a *great* starting point for fixing the i18n problems in
Fedora IMHO.
Alan

[Pedro Morais]

Post by Paul Gampe
Red Hat's internal localization team still has a considerable backlog of
work related to the Enterprise Linux 3 launch. We are hoping by
mid-December to be able to get back on track with the Fedora releases.
We are very excited by the strong support of community translators though,
and hope to have the time soon to be able to better coordinate these
efforts.

One first small step would be to somewhat generate a list of i18n update dates
for each of the packages on a release.

I understand that a package won't be regenerated just because I commited an
update to a translation (in the betas, for the final release there should be
a "Ok, day x all packages will be regenerated even if otherwise necessary
just to include translation").

But at least I could when testing a beta look at CVS history and notice that
at the day/hour of that last i18n fetch the package was 100% translated and
any problem must be in the package. And I think this process is not as simple
as "look at the build date of the RPM".

Anyway Paul, I do think you are doing a good job overall.

Post by Paul Gampe
Paul

Post by Pedro Morais
Another "acessibility" issue is internationalization; the current process
isn't bad at all, but could be improved.
I was unfortunately very busy during this beta period (only managed to
follow the mailling lists and update portuguese translations), so I can't
really complain, but I kept i18n stats at 100% at almost all tims, and
certainly at the freeze point I'm sure that only the anaconda docs has a
couple of untranlated, and still there are powerdown messages in english
(in the middle of portuguese messages, so it's not a "too late for i18n
issue") and, even worse, up2date/rhn_register is half translated/half in
english.
Clearly there's room for improvement.

[Pedro Morais]

Post by Pedro Morais
Another "acessibility" issue is internationalization; the current process
isn't bad at all, but could be improved.
I was unfortunately very busy during this beta period (only managed to
follow the mailling lists and update portuguese translations), so I can't
really complain, but I kept i18n stats at 100% at almost all tims, and
certainly at the freeze point I'm sure that only the anaconda docs has a
couple of untranlated, and still there are powerdown messages in english
(in the middle of portuguese messages, so it's not a "too late for i18n
issue") and, even worse, up2date/rhn_register is half translated/half in
english.
Clearly there's room for improvement.

And, now that I read the rest of this thread :-) a tracking bug for i18n
issues, similar to the proposed for a11y could be a step in that direction.
(If it exists, i'm not aware of it)

[Jeremy Katz]

Post by Pedro Morais
And, now that I read the rest of this thread :-) a tracking bug for i18n
issues, similar to the proposed for a11y could be a step in that direction.
(If it exists, i'm not aware of it)

Yes, this is definitely a good idea. I've created an i18n keyword, but
right now keywords require bug editing access. If you want to create a
tracker, though, then that can be used to populate the keyword from
eventually.

Cheers,

Jeremy

[Hugo Cisneiros]

Post by Pedro Morais
Another "acessibility" issue is internationalization; the current process
isn't bad at all, but could be improved.
I was unfortunately very busy during this beta period (only managed to follow
the mailling lists and update portuguese translations), so I can't really
complain, but I kept i18n stats at 100% at almost all tims, and certainly at
the freeze point I'm sure that only the anaconda docs has a couple of
untranlated, and still there are powerdown messages in english (in the middle
of portuguese messages, so it's not a "too late for i18n issue") and, even
worse, up2date/rhn_register is half translated/half in english.
Clearly there's room for improvement.

Yes, and I'm here to help translating things to Brazilian Portuguese too
:) Internationalization is much important... I wanted to help because
every time I used RH and pick up the Brazilian Portuguese language for
the system, I ended up with lots of Portuguese (From Portugal) mixed
with Brazilian Portuguese. They are both Portuguese, but they have lots
of diferences, mainly in tech words.

[]'s
Hugo

[Jef Spaleta]

Post by Jeremy Katz

Post by Pedro Morais
And, now that I read the rest of this thread :-) a tracking bug for i18n
issues, similar to the proposed for a11y could be a step in that direction.
(If it exists, i'm not aware of it)

Yes, this is definitely a good idea. I've created an i18n keyword, but
right now keywords require bug editing access. If you want to create a
tracker, though, then that can be used to populate the keyword from
eventually.

Tracking bugs....
here's is my example of what a public tracking bug looks like.

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=109188

I think a11y and i18n trackers are "good things"{tm} but i don't want to
own those trackers. But if those trackers do get created i want to make
a place for them in the Fedora Triage wiki listings. I just need to make
a space for a collection of tracker bugs.

And I want to encourage someone invested in a11y and i18n to be the
owner of the associated trackers. It would be very good for someone who
is in a position to make each of those issues a high personal priority
to be the owner of each of those trackers. I'm not that person..i only
attempt to speak english and i like eye-candy too much to be invested in
a11y.


-jef"netpeep as a11y system monitoring"spaleta

[Jef Spaleta]

Post by Jeremy Katz

Post by Pedro Morais
And, now that I read the rest of this thread :-) a tracking bug for i18n
issues, similar to the proposed for a11y could be a step in that direction.
(If it exists, i'm not aware of it)

Yes, this is definitely a good idea. I've created an i18n keyword, but
right now keywords require bug editing access. If you want to create a
tracker, though, then that can be used to populate the keyword from
eventually.

Tracking bugs....
here's is my example of what a public tracking bug looks like.

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=109188

I think a11y and i18n trackers are "good things"{tm} but i don't want to
own those trackers. But if those trackers do get created i want to make
a place for them in the Fedora Triage wiki listings. I just need to make
a space for a collection of tracker bugs.

And I want to encourage someone invested in a11y and i18n to be the
owner of the associated trackers. It would be very good for someone who
is in a position to make each of those issues a high personal priority
to be the owner of each of those trackers. I'm not that person..i only
attempt to speak english and i like eye-candy too much to be invested in
a11y.


-jef"netpeep as a11y system monitoring"spaleta