Docs Successes and Needs

Thomas Canniot thomas.canniot at laposte.net
Sat Jan 6 23:26:41 UTC 2007


Le vendredi 05 janvier 2007 à 11:15 -0500, Paul W. Frields a écrit :
> I should have started this thread on Wednesday but my home schedule has
> been a bit topsy-turvy of late:
> 
> The Docs Project has been invited to participate in the next Fedora
> Project Board meeting.  We should be prepared to talk about the
> successes we've had over the past two releases and what remains to be
> done.  The way I see it, here are some starter issues.  I'd appreciate
> plenty of input, but please keep in mind that the issues should be
> things the Board cares about (e.g. blockers in other subprojects that we
> haven't been able to resolve after repeated attempts, resource needs
> that might require Real Funds -- things we can't provide by ourselves).
> 
> Successes:
> 1.  Best-in-the-world release notes, provided by the community.
> 2.  Growing contributor base, including work on additional entry-level
> to intermediate-level guides.
> 3.  Progress toward integrating with the Fedora package universe.
> 
> Future Predictions:
> 1.  Possible click-thru on Wiki will allow easier contribution without
> all the GPG+SSH+CLA+EditGroup rigamarole
> 2.  FUDCon presence will result in major updates to available docs,
> making it easier for new people to learn processes
> 
> Outstanding Issues:
> 1.  Translation Project disconnect - what do we need here in concrete
> terms?  App rewrites and process changes?  Red Hat internal group(s)
> originally had ownership of this, yet we've seen no progress in the past
> months... or year(s).

There are simple things that may be sufficient to help improving
translation.
1. make it easy to subscribe to the project in itself. It _is_ really a
pain to open that much of account to translate a string. That shouldn't.
2. do not allow people to commit as they want. New contributors (as well
as every pieces of translation) must be read over by someone more
experienced in the projet. A bit like extras packages are reviewed
before being accepted. This will avoid many mistakes in the
distribution. 
3. better communication between developers and translators. For
example :
a package sees its .pot file updated. That is the responsibility to
check regurlary for this kind of update. But developers could say on the
translation list : i'm going to rebuild the updated software into a RPM
package by (any date) and all translation done before that date will be
included.

That's all I'd like :)

>From my point of view, I don't think it could be that indispensable to
have the same webapp than Launchpad offers for translation, that is,
translation directly from the web browser. I personally don't trust any
web browser, their stability depending on the websites you are on.



-- 
Thomas Canniot
http://fedoraproject.org/wiki/ThomasCanniot




More information about the fedora-docs-list mailing list