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

Re: Processes in the L10N team (was: Desktop-effects)


El ds 25 de 11 del 2006 a les 19:32 +0000, en/na Dimitris Glezos va
> (removed -devel-list since this is a -trans-list issue)

(I think this is definitely a development issue, we are part of the
development process, or should be)

> I agree we need to fix our l10n process. I've spoken to some people and the
> presence of the gap is pretty much known. How can we fix it then?
> Here are some first ideas:
>   1. Start by documenting the need for attention to this matter, for example by
> getting some numbers of the non-english users (e.g. fedora-brazil is HUGE)

IMO this is irrelevant and reinforces the second class view of
translations that Thomas pointed out (i.e. having to justify why
translations are important). It's not a matter of how may will use a
particular translation, it's that there is no reason not to consider
translations during the development and release processes.

>   2. List irritations the translators have stated in the past. One example is
> releases not having up-to-date translations in packages [1].

Very true!

I'd add the development cycle of system-config-* (and in general all
fedora specific) apps. It'd be good if we were informed in due time
before a release is done, so we have time to translate.

Then there is this issue with maintenance releases of Fedora. How do we
update translations for FC5? Since we are only given HEAD in CVS, we
don't know how to reach older, but maintained, releases.

>   3. Start having IRC meetings to discuss things, our progress and get people to
> hang out on the IRC channel more often.

This is a very good idea, specially if developers could be involved
(although I reckon they already have a lot of other work to do). In
general developers are very cooperative people and sympathetic to
translators, but it's not unusual that translations are forgotten during
the development process.

>   4. Think about electing a Steering committee for the team; check out the
> DocsProject voting proposal:
>     http://fedoraproject.org/wiki/DocsProject/Policy/FDSCoElections

We're very different from the Documentation Project in the sense that we
don't need to decide what to document, or everything the documentation
project has to deal with (we basically know what our work is, we are not
authors). But we probably need a committee that can make our voices
heard in the fedora development/release process, so I think it might be
a good idea.

Probably we should first think what we want the committee for (we could
start another thread if people agree).

>   5. Start writing guidelines for developers and slowly try to make them happen.
> A steering committee can help with this by having open communication channels.
>   6. Open up a wiki page holding links to common/known problems, a bug tracker
> for translation bugs (is there one?) and start pushing release-blocker bugs for
> important issues.
>   7. Get the team closer to the Docs project; this team does a *great* job and
> the two teams have a lot in common and could share experience, tools etc.
> The L10N project shouts "I need resurrection" with all it's strength. So, to
> have something to hold onto, I copied the above points here:
>   http://fedoraproject.org/wiki/L10N/Tasks
> Ideas, comments, suggestions?

Very good initiatives and points all of them, although, as I mentioned,
I'd remove point 1.


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