Re: Localization in goffice-bits

On Thu, Aug 9, 2012 at 12:48 PM, Jean Brefort
<[email protected]> wrote:
>
> IMHO, the right way would be to use goffice itself when we get a new
> stable release, now that the license is either GPL-v2 or -v3, and get
> rid of goffice-bits which is not maintained. We can use a --without-gtk
> build of goffice for the non-gtk build.

I would second the idea that the right way to use upstream bits is to
pull them from the upstream (including their L10n), rather than
maintaining local duplication.

To that end (and specifically with regards to L10n), I have created a
dummy PO file to act as a "tracker ticket" on the status of upstream
goffice L10n.

goffice_upstream_L10n_tracker.po

I will be rolling it out into language projects on Pootle soon.

As explained in the developer's comment of the PO file:

As is the case with many FOSS projects, AbiWord uses code (and UI
strings) from upstream projects.  In order to ensure a fully localized
user experience, it is necessary to work on the upstream L10n so that
those bits flow back downstream to our users.  AbiWord uses goffice
for things like color pickers, etc. and so we want them to be 100%
localized.  Please follow this link and contribute to the L10n of
goffice in your language so that we get those bits when we pull the
goffice code.

http://l10n.gnome.org/module/goffice/

This is also know as "showing some love to the upstream" and it is a
very FOSS concept.

If you check the upstream and see that their localization of this
packagee is complete in your language, simple translate the status
string as "Complete" and the date checked in ddMMMyyyy format (e.g.
"Complete 14APR2011") to let other localizers know to look elsewhere
for bits to localize.

cjl