incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Louis Suárez-Potts <lsuarezpo...@gmail.com>
Subject Re: [DISCUSS][WWW] Native-Language Sites (was: Current Polish web site -- pl.openoffice.org)
Date Thu, 10 Nov 2011 19:04:44 GMT
Hi,


On 10 November 2011 13:46, Rob Weir <robweir@apache.org> wrote:
> It is not clear to me whether the diversity in N-L pages was by design
> or simply from lack of coordination.

Intentional. My purpose in permitting the project leads in N-L (and
for that matter, all the other projects) was based on two principals:
1. pragmatic reality: I didn't have the time to inspect, police,
correct all that I envisioned being created, nor did I want to; 2. I
believed then and believe now that local autonomy allows for fastest
growth and expansion. And I was right.

That said, I did have some provisions in place. No ads, for instance,
and no offensive material; and the trademarked material could not be
altered. As well, I encouraged colour coherence, and, of course,
strongly urged parsimony when it came to creating project lists.
License had to be the same as the domain-wide licenses. (We did
grudgingly allow for some projects to differ, e.g., the Authors' group
associated with Documentation, as they strongly argued for CC
licenses. As well, the wikis we used could have been clearer as to
which licenses were permitted and what the relation of the wiki was to
the other domain projects.)

Charles and I posted suggestions at http://native-lang.openoffice.org/
(Charles was effectively appointed to front the N-L category but did
little in actually scripting the policies or imposing them.)


 Just has, for example, all
> Apache pages have a similar navigational structure, as well as
> mandatory content, I think we should enforce the same for N-L pages.
> Remember, these pages represent the AOOo project, and therefore
> Apache, to visitors who may never see the main English project page.
> So we need to make sure that all of our bases are covered in on that
> page: license, how to download, ToU, mailing lists, support forums,
> etc.  And this needs to be done for any entry point the user makes.
> So I think we're better off with a cookie cutter approach for the
> webpages, with specific areas for extensibility according to N-L
> needs.

I agree. The issue with the wiki on OOo is a case in point. We need to
make it very clear at the outset. There were several attempts to do
this, and we can repurpose them, I daresay.

The license and aesthetic claims for N-L projects can also be a)
repurposed and b) strengthened, if that is our desire. I think at this
point, it is. But we also have to clarify what the N-L projects are to
be about, if we wish to reconstitute them. On OOo, I designed them to
be about education, information, and local marketing; not coding,
though localization was strongly encouraged. Primarily, the N-L
projects differed from l10n, where coding and much localization was
done, in that discussions on N-L lists were in the native tongue of
the speakers. I saw this as important and as a powerful lever to open
the market. I was right.

(That said, it was always my goal and design that the N-L projects
would evolve to include more development. There were very few
developers of OOo code, and my reasoning was that by progressively
introducing OOo both as a product for users in their language, and as
a community who operates in their language, and as code they can work
with—they would take to it, either out of personal desire or for
commercial reasons, even though all code discussions had to be in
English. Again, it seemed I was not incorrect in this reasoning, but
it just took too long and I had too little support from the
contributor companies who by and large could not see the point of the
N-Ls anyway.)

But I'm not sure that Apache would be right for that kind of logistic,
where there are any number of projects operating in the native tongue
of the speaker, though where all coding discussions must be in
English.

However, I do think re-using (or just using plus updates) the extant
language for the OOo N-L projects ought to be considered.

-louis


-louis

Mime
View raw message