Re: [native-lang] Regional mentors/leads

2008-01-11 Thread André Schnabel

Hi,

and thanks for bringing the proposal to a public list.

Louis Suarez-Potts schrieb:




* I want to be a Regional Community Lead! I want to be a Regional 
Community Lead! What shall I do?
Simple. Write to the [EMAIL PROTECTED] list a proposal and we'll take 
on from there.


Oh, I never even thought of that 8-)
About what? That more people want to become Regional Community leads or 
thet they should ask at a public list about that.

While I am looking forward to the first, I hope the latter is obvious ;)

If I get all this right, (and sorry for the very German style to get all 
things in structures), regional Community leads will have similar tasks 
like Native Lang Community leads have now. Bu they will step in at 
locations where that language-based "Community-Setup"does not work very 
well (e.g. Inda, Africa because we have a mix of languages in a given 
region - or US, Australia, England, because we have only one language in 
different regions with different cultures)?
Looking at the structures those regional leads need to have close 
contact with the native lang projects (of their region as well as 
global), correct?


You know, sometimes I do presentations about our poject's structures and 
hw you can join. So I just like to know, where all thiswould  fits in.


André

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [native-lang] Regional mentors/leads

2008-01-11 Thread Louis Suarez-Potts

Hi
On 2008-01-11, at 11:54 , Charles-H. Schulz wrote:



* I want to be a Regional Community Lead! I want to be a Regional  
Community Lead! What shall I do?
Simple. Write to the [EMAIL PROTECTED] list a proposal and we'll take  
on from there.


Oh, I never even thought of that 8-)

But i'd modify it by suggesting that for now, I'd like to have just  
one, the one for India, and see where we go from there.





Hope this helps,

Charles.


Thanks,
Louis

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [native-lang] NLP page and project list

2008-01-11 Thread Louis Suarez-Potts

Hi

On 2008-01-03, at 03:03 , Clytie Siddall wrote:




My turn to be confused.

Maybe I'm confused about this, but I thought the idea of getting us  
all to update the wiki list was to have one canonical list from  
which, if necessary, other lists or information could be updated.


Surely we don't have to file a separate issue to get this list in  
line with the wiki list?


Well, the point of an issue is that it reminds us directly. I'm on  
many many mail lsts and am constantly being asked to do small things,  
also big; having an issue helps.


But I also would rather just have *one* list. I think having parallel  
lists is (evidently) a pain.





from Clytie


best
louis

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [native-lang] Regional mentors/leads

2008-01-11 Thread Charles-H. Schulz

Louis, all,

Apologies for an even longer post...


Louis Suarez-Potts a écrit :

Hi all,

This is not exactly a new proposal--we have discussed it on-list and 
off and on for years--but I'd like to raise it formally here for 
discussion. The proposal is to establish a more or less formal role, 
"Regional Community Lead."  One could also call it, as I used to, 
"Regional Mentor", but the term, Regional Community Lead is probably 
more descriptively accurate. I would also like to propose that we 
start with this role in India.


* Reasons for the role

In some regions, the community needs people local to that region who 
can ably represent OpenOffice.org to regional Foss groups, 
universities, government, wherever.  The NLC leads do this now and do 
it well. But they are tied to particular languages--that's the 
point--and are not regional, though obviously, in practice, for many 
languages they are.


But in places such as India, where there are something like 21 
official languages, I and others believe that we need someone who can 
effectively unify the disparate groups and represent OOo.  That person 
would also work as a regional mentor and help new community members 
learn OOo; and would also necessarily have a tight connection with the 
developer and contributor members. Of course, any other community 
member could establish such connections, and in fact that's the 
goal--to get more developers, world-wide.  But in places such as India 
(or Africa or North America, and elsewhere), a regional lead who can 
help unify the local community seems required.


And I think it's important to act now. The case of India is the 
prompt.  When we went to Foss.In last December, and used it as our 
Indian Regional Conference, we were delighted to see that the Foss 
community in India was eager, friendly, vibrant, but dismayed to 
discover that there was no coherent OpenOffice.org community. It was 
atomized; work was being done by the government sponsored CDAC, and by 
Red Hat, and by a couple of independents, but there was no real 
community that could reliably share things. What's more, I learned 
that much of the source that was being worked on by the disparate 
communities was not coming from OOo repository; and there were many 
minor forks. There was in short a bit of a mess.


The solution, it was impressed upon me, was to have a more visible 
presence in India. I don't mean Sun; I mean OOo. OOo may be used by 
millions there, but few work on it, and they don't work on it because 
for many, the obstacles of working on it are too steep and because 
there was no real community there. India depends on CDROMs and 
personal contact, and appreciates the visible efforts of the 
community. (I'm also trying to form a Sun team in India that can help 
nucleate the effort; but that is different from this proposal.)


That visible presence is substantially achieved by establishing a 
Regional Community Lead: someone who can knit the various groups 
together and someone who can help coordinate overall communication 
among the international and regional groups.


So, my apologies for the long post.  But I do have a few more points:

* Does this add bureaucracy?
I hope not. Rather I hope it does the opposite.

* How formal is this role?
It is formal enough to grant the holder the ability to use it tactically.

* Does this mean that regional community members must go through him 
or her to reach OpenOffice.org?
No. Rather, it means if anything that the regional community lead will 
*help* those who want that help and strive to establish active 
participant communities.


Thank you, Louis. I would also add some other elements:

*What do we do with existing "NLC Regional Groups"?
Nothing, or rather, the Regional Community Lead is in a way the 
continuum of what the Regional Group Coordinator was, but with a more 
formal entitlement.


* Are Regional Community Leads supervising Native-Language Project Leads?
Not at all, these are two very different roles. One may see this new 
role as a regional coordination role.


*Do we have to have a Regional Community Lead?
No, we are not imperialists... :-)

*I want to get things done with the native-lang project(s) that happen 
to work in a region/country/city near me, but I'm not part of that team 
or I work with a different native-language project as our language is 
different. How do I do that?
Perhaps you could think of having a Regional Group and a regional 
community lead...


* I want to be a Regional Community Lead! I want to be a Regional 
Community Lead! What shall I do?
Simple. Write to the [EMAIL PROTECTED] list a proposal and we'll take on 
from there.


Hope this helps,

Charles.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[native-lang] Regional mentors/leads

2008-01-11 Thread Louis Suarez-Potts

Hi all,

This is not exactly a new proposal--we have discussed it on-list and  
off and on for years--but I'd like to raise it formally here for  
discussion. The proposal is to establish a more or less formal role,  
"Regional Community Lead."  One could also call it, as I used to,  
"Regional Mentor", but the term, Regional Community Lead is probably  
more descriptively accurate. I would also like to propose that we  
start with this role in India.


* Reasons for the role

In some regions, the community needs people local to that region who  
can ably represent OpenOffice.org to regional Foss groups,  
universities, government, wherever.  The NLC leads do this now and do  
it well. But they are tied to particular languages--that's the point-- 
and are not regional, though obviously, in practice, for many  
languages they are.


But in places such as India, where there are something like 21  
official languages, I and others believe that we need someone who can  
effectively unify the disparate groups and represent OOo.  That person  
would also work as a regional mentor and help new community members  
learn OOo; and would also necessarily have a tight connection with the  
developer and contributor members. Of course, any other community  
member could establish such connections, and in fact that's the goal-- 
to get more developers, world-wide.  But in places such as India (or  
Africa or North America, and elsewhere), a regional lead who can help  
unify the local community seems required.


And I think it's important to act now. The case of India is the  
prompt.  When we went to Foss.In last December, and used it as our  
Indian Regional Conference, we were delighted to see that the Foss  
community in India was eager, friendly, vibrant, but dismayed to  
discover that there was no coherent OpenOffice.org community. It was  
atomized; work was being done by the government sponsored CDAC, and by  
Red Hat, and by a couple of independents, but there was no real  
community that could reliably share things. What's more, I learned  
that much of the source that was being worked on by the disparate  
communities was not coming from OOo repository; and there were many  
minor forks. There was in short a bit of a mess.


The solution, it was impressed upon me, was to have a more visible  
presence in India. I don't mean Sun; I mean OOo. OOo may be used by  
millions there, but few work on it, and they don't work on it because  
for many, the obstacles of working on it are too steep and because  
there was no real community there. India depends on CDROMs and  
personal contact, and appreciates the visible efforts of the  
community. (I'm also trying to form a Sun team in India that can help  
nucleate the effort; but that is different from this proposal.)


That visible presence is substantially achieved by establishing a  
Regional Community Lead: someone who can knit the various groups  
together and someone who can help coordinate overall communication  
among the international and regional groups.


So, my apologies for the long post.  But I do have a few more points:

* Does this add bureaucracy?
I hope not. Rather I hope it does the opposite.

* How formal is this role?
It is formal enough to grant the holder the ability to use it  
tactically.


* Does this mean that regional community members must go through him  
or her to reach OpenOffice.org?
No. Rather, it means if anything that the regional community lead will  
*help* those who want that help and strive to establish active  
participant communities.


Thanks
Louis


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [native-lang] Resent: Multilingual Wiki Layout

2008-01-11 Thread sophie gautier

Hi Frank, all,

Frank Peters wrote:

Resent: Added Reply-to [EMAIL PROTECTED]

Sorry for crossposting, this may be interesting to multiple groups.
---

Native Lang Leads,

I have been talking about the layout of the Documentation section
in the OOo wiki at OOoCon this year and have been discussing this
matter with some of you in person or via email.

I would like to describe the problem again in this mail and
propose solutions. I would also like to ask you to give your
opinion soon so we can move to a multilingual docs approach soon.


Thank you for this.


We are focussing on implementing a solution on the wiki.
I know that there are other options but they would include the
usage of other tools and processes and those would require
additional setup, maintenance, and learning effort. These
may be an option later after we had a chance to go through
a thorough evaluation phase. But for now I would like to
approach that pragmatically.

PROBLEM STATEMENT
-
The Documentation project created a structured subsection of
the OOo wiki that is intended to carry all documentation
content to allow easy collaboration (there may be exceptions
to the rule but they are out of scope for this discussion).

a) Many native language communities have created a rich set of
   documentation that is not available in other languages.

b) The Documentation project contains much content that is
   not or only partly available in other languages.

c) Switching between languages in the wiki is not
   straightforward


PROPOSED SOLUTION
-
The solution would include having a fixed agreed-upon structure
for documentation that would allow to place different doc
languages side-by-side.

If all languages follow the same, well-defined structure scheme
it would be easy to implement a language switcher in the wiki
that does the switch programmatically without having to
maintain matching tables.

This only applies to documentation. The mother native-lang
project may still keep its wiki structure as preferred.


Ok,


IMPLEMENTATION
--
The structural scheme of the Documentation wiki content is as follows:

wiki/Documentation/$DocTypeOrBook/$SubSections/$SubSubSections

Examples for $DocTypeOrBook are
- FAQ
- HowTos
- OOoAuthorsManuals
- BASIC Guide

Examples for $SubSections are
- FAQ/Writer
- Howtos/Calc
- OOoAuthorsManuals/Getting Started Guide
- BASIC Guide/Language

$SubSubSections are furthr subdivisions (if required). I think you get
the idea.

The idea is to maintain a parallel structure for "native languages"
alongside the docs, for example:

wiki/Documentation/FAQ  for FAQs in en, or
wiki/Documentation/en/FAQ   for FAQs in en
(would require move of topics in the wiki)
wiki/Documentation/fr/FAQ   for FAQs in fr
wiki/Documentation/de/FAQ   for FAQs in de

Likewise, for a particular FAQ, for example:

wiki/Documentation/FAQ/Writer/General/HowToFormatACharacter (in en)
wiki/Documentation/fr/FAQ/Writer/General/HowToFormatACharacter (in fr)
wiki/Documentation/de/FAQ/Writer/General/HowToFormatACharacter (in de)

The langugage ISO code after the wiki/documentation part
of the path would be the identifier. This approach would allow
to use Google to either

* search documentation in all languages by searching
  through wiki/Documentation

* search documentation in a particular languae by searching
  through, e.g. wiki/Documentation/fr
  (this would require to move all English documentation to
  wiki/Documentation/en)

Switching languages would be handled by a language bar
that is easy to be set up and switches languages by
changing the language ISO coide in the URL.

*However*, this requires the wiki pages to share a common
page name. In the current mediawiki version, this page
name is also displayed as the page title. I understand that
it is inacceptable for a non-English wiki page to display
an English page title.

With the updated wiki engine (that will hopefully be available
soon), however, we will get the DISPLAYTITLE functionality that
allows a different title to be displayed. This would allow the
pages to share a common page name, but still display a
localized title.

We would also need to agree upon a wiki page title scheme
that makes it easy to handle the URLs. Engslih being the
lingua franca of IT, I propose to use English page names
for the wiki pages. That means, even if you create a French
page inside the French Documentation hierarchy it would need to
have an English page name (that would only affect its URL!).


This is the difficulty I see here. The wiki is open to every body, how 
do you do if do not know a word of English?


We also need to have a basic migration strategy in place to
handle existing documents without too much hassle, meaning
moving them to the new hierarchy and possibly renaming them.


yes, and take care to update the links added to the OLH.


The result of all this would be that a Documentation page
contains a language bar marking the c