[Fwd: Translations: String freezes, CVS converging, Packaging]

Renato Pavičić repavici at globalnet.hr
Wed Mar 7 16:26:09 UTC 2007


Dana Wed, 07 Mar 2007 16:33:02 +0100, Dimitris Glezos  
<dimitris at glezos.com> napisali ste:

> O/H Renato Pavičić έγραψε:
>> I always had trouble
>> inserting translation into Fedora (ususaly I wait for a official
>> realease). On KDE its quite easy - just download the daily langpack
>> build that is automatically genereated and install it using few kosole
>> scripts.
>
> If we package translations in a different package than the application,  
> then we
> can push updates of translations whenever we want through the update  
> system and
> yum, like any other package. So, no need for extra shortcuts etc. :)

Well, yeah, you are correct on this one. What I meant is that with the  
option that you've just describe it will not be difficult to add such  
shortcut or some other shortcut regarding localization. And this could be  
VERY helpful for teams that need support/help. For people that understand  
English well it is not common that an option to contribute with bugreports  
or localization effort is not first item on thier list. This could be like  
some reminder "you can help us" :)

[snip]
>> I would suggest creation of addtional module that would provide (to
>> enduser) following options:
>> - update of language (translation) only, automatic or manual
>> - feedback report about translation (report will be sent to translator
>> of correcponding module, lang team coordinator and lang team bug report
>> page)
>
> For the second, we plan to create a separate Component on Bugzilla called
> "Fedora translations" so that bugs will be filed directly to the  
> maintainer of the language. If we really like to make it even simpler  
> than that, then we'd need to discuss it more (like, create a more simple  
> web page like a pre-bugzilla one with just a drop-down (lang) and a  
> Comments box.

The shoter procedure - the better. End-users should have an option for a  
one or two click acces to lang report, with most automatic  
insertion/detection of package and term possible.

> I think at this point we need to decide whether or not we are ready to  
> have multiple packages & maintainers or a single one.
> If we have one package, then its going to be big and harder to maintain.  
> An update to one language will need a whole repackage. On the other  
> hand, having each language its own pack means some people from here will  
> need to step forward as Language maintainers/coordinators and learn how  
> the update system works.
> Thoughts?

I have no problem with such option. My support to this one. I work on  
serveral localizations, various types of applications, filetypes and OS's,  
and from my experience having a separate langpacks is always the best  
option.

Considere just this: in case a translator accidentaly screws up his/hers  
local copies, he/she is not obliged to download ALL languages. I know  
there are people out there with flat rate 10Mbps, but for me, it's like  
you live on Mars.

On the other issue, frankly speaking, I have no clue on programming  
procedures involved, but I guess it is not impossible becues gusy on KDE  
did that (appologize to all Gnome lovers for mentioning KDE so offten ;) )

Check the layout and info provided on their i10n site and statistics:
http://l10n.kde.org/

On individial team pages there are langpacks to download. I beleive they  
are daily build and that there is an option for team coordinator to run  
appropriate script? Will check with them. I strongly beleive they wil be  
very glad to help.

Reorganization of Fedora localization is needed. There are quite a lot of  
modules now, lot of a languages and lot of a people working on. Even some  
smaller projects have their l10n sites and project organized in a better  
way.


-- 
Best regards,
Renato Pavicic

mailto:repavici at globalnet.hr
also mailto:renato at translator-shop.org
homepage: www.translator-shop.org

Official Opera translator for Croatian language since April 2006




More information about the Fedora-trans-list mailing list