Re: [PATCH] Automatize creation of DATA lists for Makefiles

On Tue, May 15, 2012 at 3:46 PM, Ingo Brückl <ib@wupperonline.de> wrote:
>
> Chris Leonard wrote on Tue, 15 May 2012 15:11:17 -0400:
>
>> I do propose the removal of these unused (or deprecated) variants of
>> languages.
>
> In general, we shouldn't dump existing translations. (They was already a
> discussion on that.)
>
>> ar_EG
>> ar_SA
>> de_AT
>> en_NZ
>> en_ZA
>> es_AR
>> es_IR
>> fr_BE
>> fr_CA
>> fr_CH
>
> There are no .po files for these in svn, i.e. they can't be removed because
> they don't exist for AbiWord.

However lines for these apparently exist in two of the Makefiles, and
it is from there that they should be removed to leave the code as
clean as possible.

user/wp/Makefile.am
user/wp/templates/Makefile.am

>
>> en_AU
>> en_CA
>> en_IE
>> es_MX
>
> There are .po files in svn. What's wrong with these?

I am deeply committed to linguistic self-determination and I maintain
a Pootle instance with 130-odd languages (or variants). I am not
however in favor of maintaining meaningless distinctions and doing
extra work when it makes no real difference.

Simply because it is possible to make a distinction does not mean it
is worthwhile to do so. The vocabulary from which a word processing
program draws (even one as fully featured as AbiWord) is a limited
universe of phrases. Were this a program that were rich in culinary
or cultural terms, I might make the opposite argument, but it is a
word processing tool. Certain distinctions are common in FLOSS L10n
(pt, pt_BR, en_US, en_GB, various script variations in Slavic
languages between Cyrillic and Latin alphabets, etc.) and they make
sense because they are meaningful to users.

Sugar has a large deployment in Australia via OLPC Australia and even
they do not want to maintain a separate en_AU set of translations,
they may pick up en_GB strings for the orthography differences. I
would also note that 5280 of 5394 words in en_AU are not translated,
so little work would be lost. Essentially the same argument goes for
en_CA and en_IE variants.

I consult regularly with representatives of large user communities
(one million plus) in numerous Spanish speaking countries (Peru,
Uruguay, Paraguay, Mexico, Nicaragua, etc.) and the consensus is that
for written Spanish, the effort to maintain variants is not worth it.
We use a single lang-es project for all.

F Serrador did make a concerted effort to go through the es_MX PO file
and togehter we did identify some strings where the translation was
potentially superior to the existing es_ES translations and these were
incorporated into es-ES, so again, no useful work would be lost by
dropping es_MX, but a maintenance burden would be reduced.

Written Spanish does not represent the differing sounds of regional
Spanish variants (the yeismo and seismo, for instance). If this were
e-speak, I would be arguing for multiple variants as they would be
meaningful, but n Spanish word processing, there is little meaningful
national variance in the vocabulary of the user interface.

There were no strong objections to dropping these variants when I
raised it previously in June 2011.

http://www.abisource.com/mailinglists/abiword-dev/2011/Jun/0015.html

There were even supportive replies (for the en variants)

http://www.abisource.com/mailinglists/abiword-dev/2011/Jun/0000.html

cjl
Sugar Labs Translation Team Coordinator
Received on Tue May 15 22:52:55 2012