Language committee/Archives/2007-03

Belarusian Wikipedia

This is a series of email discussions about the request for a Belarusian normative Wikipedia. The question was forwarded to the board of trustees, which ordered the creation of the wiki using the be subdomain, moving the Belarusian alternative Wikipedia to be-x-old.

Request for news

Bèrto 'd Sèra
02 March 2007 09:56

Hoi!
I get requested new about the Byelorussian wiki. Do we have any?

-----Original Message-----
From: Yury Tarasievich
Sent: 02 March 2007 15:15
To: Berto 'd Sera
Subject: Re: [Wikipedia-l] Translating the Five pillars
Привет
Хотелось бы узнать, в каком состоянии наш беларуский вопрос? Целесообразно ли дожидаться? :)
Ю.Т.
Jesse Plamondon-Willard (Pathoschild)
02 March 2007 14:20

Hello,
No news yet. We're just beginning pushing requests through the process, so news should not be much longer delayed.
Bèrto 'd Sèra
CC Yury Tarasievich
02 March 2007 14:57

Еще раз привет!
Что касается самого вопроса о вашего вики, думаю, что скоро уже все будет, раз начинается создание новых вики уже по системе комитета. Board обсуждает вопрос о передачи вам домейна бе.вики согласно рекомендации комитета.
Домейн для проекта Итер только что покуплено. Через пару дней уже что-то будет видно.
Gerard Meijssen (GerardM)
02 March 2007 16:41

<this user has not agreed to public archival.>
Sabine Cretella
03 March 2007 06:35

Maybe a stupid question: but how do you push the requests through the process? I mean: it is not up to us to decide what happens, we can only say "this is how it should be handled" and this is exactly what we did up to now. We don't have a position that allows us for an official decision.
Jesse Plamondon-Willard (Pathoschild)
03 March 2007 13:56

Hello Sabine,
The language proposal policy<http://meta.wikimedia.org/wiki/WM:LPP> describes a streamlined process each request follows (proposal, discussion, test project, decision). The subcommittee approves or rejects a request based on the prerequisites and discussion. Our decision is not official; when a proposal is suitable, we forward a summary and recommendation to the board, and they make the final decision.
Pushing requests through the process involves these steps:
[a] ask for information needed to make a decision, if any is missing;
[b] make a conditional decision and notify all interested users about the test project;
[c] make a final decision and forward a summary and recommendation to the board.

Request for news 2

Bèrto 'd Sèra
21 March 2007 23:18

Hi Erik!
I know we are all overburdened with lots of stuff (I'm writing this at 6.14 am myself and I haven't gone to sleep, yet). I would not bug you for just any issue, but I feel these guys do deserve a direct answer. They have been working for months in a weird situation, it's just human that they will want to know whether their work is worth doing or not.
Thanks :)
Gerard Meijssen (GerardM)
22 March 2007 02:05

<this user has not agreed to public archival.>
Bèrto 'd Sèra
22 March 2007 20:33

Hoi!
Thank God, finally something new on the western front :) I'll keep a bottle ready for the event :)
Bèrto 'd Sèra
23 March 2007 09:38

Hoi Yuri!
I'll answer in English, because I'm copying the message to people who do not speak Russian. Moreover, sorry for being slow in answering, I actually moved this message in another folder upon receiving it and then forgot about it. For all who had not received the original msg from Yuri I'll leave the whole original text appended after my answer.

> 1. On the naming of the "other" version: I'd again suggest something
> like be-nn (from the abbreviated name of the cult newspaper) or
> be-alternative (which is how linux locale would *seemingly* be named
> -- http://sources.redhat.com/bugzilla/show_bug.cgi?id=4020).

As you already know the Board just gave Brion official instructions to rename the domain according to LangCom recommendations.
IMHO it would be fair if the new Byelorussian wiki had a pointer to the older version in its first page (and a NEUTRAL explanation of what's happening, PLEASE make DAMN SURE it's neutral), for at least a couple of months. We all need to put to sleep as many flames as possible right from the start.
I'd also say we should welcome any possibility of getting more flavors of the Byelorussian linguistic entity under a standard. From a strictly "political" POV I'd rate it nice if the new bel.wiki and bel-x-old could be together in requesting such a valid ISO code (for linux, too). Being decent cooperative neighbors is always much better than wasting time on wars, believe me.
A final decision about shutting down bel-x.wiki has not been made, yet; wmf will need time to put up a Meta ArbCom that will have decisional power on the issue. We all hope that there will be no decision to be made (because the two communities will have evolved into "friends") by the time Meta ArbCom is in place.

> 2. There may once again emerge the "argument" of the "orthography
> converter",

We all welcome experiments and I'm 100% sure that there are valuable efforts and results in what the bel-x-old team is doing for the protection and restoration of ancient linguistic proximities; yet their linguistic flavor is NOT what an ISO 639-3 BEL code describes. Any converter is irrelevant in this issue.

-----Original Message-----
From: Yury Tarasievich Sent: 22 March 2007 09:58
To: Berto 'd Sera
Subject: Re: Inquiry as to the any news on the Belarusian WP?
Thanks, Berto!
That bit of a help was Much Appreciated!
Understandably, I won't forward such nebulous prognosis to the team yet, lest this proved some false hope. We already lost (though not irrevertably, I hope) some good editors because of this "weird" situation.
Sorry for the lengthy fragment that follows, it could be relevant.
1. On the naming of the "other" version: I'd again suggest something like be-nn (from the abbreviated name of the cult newspaper) or be-alternative (which is how linux locale would *seemingly* be named -- http://sources.redhat.com/bugzilla/show_bug.cgi?id=4020).
2. There may once again emerge the "argument" of the "orthography converter", which may "really work any time soon now" or "some day in future anyway". Now, *strictly technical* refutation on that is as follows:
2.1. Differences between the two versions of the Belarusian language are well beyond the "mere orthography", and *additionally* comprise different alphabets, significant differences in the morphology, strongly and intentionally diverged vocabulary (references could be provided but would be all in Belarusian and point to paper books, I'm afraid).
2.2. Given the language versions' differences, such converter would need to function on the level of the human translation, which is just that unrealistic.
2.2.1. Even on the "strictly orthographical" level, it would need to be fed with almost two quite voluminous lexicon sets (because of stress position, which tends to move in the Belarusian language, and determines some orthogr. aspects, nevertheless).
Thanks again and feel free to forward my thanks (and other info, too) to the other folks involved.
Bèrto 'd Sèra
23 March 2007 23:02

Hoi!

>On the pointer presence per se you have my personal assurance. In
>fact, I'd add it anyway, even if unprompted (sort of like the
>Norwegian wikis do it).

Perfect, that's the best model I can think of.

>The issue of the neutrality of the explanation is harder, for while I
>could claim I'm sort of the biggest expert on the issue in this
>(wikipedia) community, and while my account of the factual side of the
>issue was never challenged, and may be as close to neutral as it gets,
>still it seems to generate emotional, not rational, response,

I think you can simply quote the Board's decision and the LangCom recommendation that led to this move without any comment from your side. Maybe it can help quoting the Norwegian as an example of fair play behavior and asking everyone to work for a productive coexistence of both editions.

...
>>together in requesting such a valid ISO code (for Linux, too).
>While it seems there exist such intentions, the actual cooperative
>output remains a thing to be seen, of course.

I'm also told that there are little hopes for an ISO code to be issued (if any). Anyway, under the present conditions the very process of a joint request is more effective to keep the Byelorussian waters quiet than its final outcome. Eventually a Linux local coming out for the other Byelorussian flavor can help in setting at least a "de facto" standard.

>I don't understand why the shutting down even enters into it. This
>never was asked for by "our" community, we just wanted the rightful
>code to point to the right community.

Nobody says anyone from Belarus' ever requested any shutdown. This is but an internal wmf issue and has no relation whatsoever with any of your requests. We don't make any special policy for Belarus'; we simply deal with a set of tens of hundreds of linguistic ISO codes and need a sensible unified policy to manage them.

>So, please, do not shut anything down.

Perfect, then let the two Byelorussian communities get together and challenge the pro-shutdown point. Have my personal word that LangCom shall formally acknowledge any official be.wiki request not to shut down be-x-old.wiki if your community will issue such an official request (a joint official request from both editions is going to be acknowledged even quicker). Whatever will happen from here on must show a clear responsibility pattern. It's time we all get rid of conspiracy theories.
Regarding MetArbCom future decisions on the issue, you guys are welcome to collect scientific material and prove your point in defending be-x-old. MetArbCom will have a lot of work within the post-communist space, as you can imagine, and it won't be set up tomorrow morning anyway. Given the usual wmf setup timings I would not expect any such decision to be taken before a year or so. Even if it happened any quicker than that if both editions issued a joint request to allow a time extension for the gathering of scientific evidence their request would definitely be heard.
WMF Committees are not the Holy Inquisition or Gestapo squads; we simply analyze technical issues based on technical evidence and eventually make technical recommendations/decisions. We are NOT going to tolerate any repetition of the hysterics that often took place when purely emotional/political votes where cast, that's for sure, yet data and scientific evidence always were/are/will be welcome.
One last practical recommendation for future proceedings: using terms like Narkomauka and Kommunjaki (or ethnical derogative terms) has had and will have the same disqualifying impact as writing a WW2 history with terms as Naztards (Nazi bastards), Axiots (Axis' idiots) and the like. Everyone is free to have whatever political beliefs he/she rates better but we are writing an encyclopedia here, not a satirical pamphlet. Let's make 200% sure we all choose a wording that is consistent with our job, please. Obviously a correct wording per se does not make an encyclopedia; articles also need clearly traceable sources and a basic equilibrium between conflicting POVs.
AFAIK this never affected you as an individual, but we both know how this sadly IS a recurrent issue in most post-communist wikiquarrels. Be aware that together with linguistic issues and political flame wars the "this is not a wiki" argument (if proved) is going to be the shortest path to instant shutdown.

> Please feel free to forward this if necessary etc.

I just did it :) This mail is also public and can be forwarded as you please. We have no secrets :)
God luck for your new wiki :)
DISCLAIMER: what's written here represents my own personal POV only and can NOT be considered as an official WMF LangCom statement in ANY way.

-----Original Message-----
From: Yury Tarasievich
Sent: 23 March 2007 17:04
To: Berto 'd Sera
Subject: Re: Inquiry as to the any news on the Belarusian WP?
Hello,

On 23/03/07, Berto 'd Sera wrote:
...
> IMHO it would be fair if the new Byelorussian wiki had a pointer to the older version in its first page (and a NEUTRAL explanation of what's happening, PLEASE make DAMN SURE it's neutral), for at least a couple of months. We all need to put to sleep as many flames as possible right from the start.

On the pointer presence per se you have my personal assurance. In fact, I'd add it anyway, even if unprompted (sort of like the Norwegian wikis do it).
The issue of the neutrality of the explanation is harder, for while I could claim I'm sort of the biggest expert on the issue in this (wikipedia) community, and while my account of the factual side of the issue was never challenged, and may be as close to neutral as it gets, still it seems to generate emotional, not rational, response,

...
>together in requesting such a valid ISO code (for linux, too). Being decent cooperative neighbors is always much better than wasting time on wars, believe me.
While it seems there exist such intentions, the actual cooperative output remains a thing to be seen, of course.

...
> A final decision about shutting down bel-x.wiki has not been made, yet;

I don't understand why the shutting down even enters into it. This never was asked for by "our" community, we just wanted the rightful code to point to the right community.
So, please, do not shut anything down.

> > 2. There may once again emerge the "argument" of the "orthography
> > converter",
> We all welcome experiments and I'm 100% sure that there are valuable
...

I just wanted to keep you and folks from langcom properly informed. We all know how irrelevantly the "red herring" arguments tend to be used, after all, and how the people acting "on behalf" of somebody (langcom "on behalf" of "our" community) could be made to look bad if uninformed and confronted even with irrelevant info.
Please feel free to forward this if necessary etc.
Best regards and thanks!

Localization

Bèrto 'd Sèra
25 March 2007 03:57

Hi !
Will anyone point me to a contact in Betawiki? We need to put up an account for the new be localization team. They have a ready PO file to upload.
Sabine Cretella
25 March 2007 13:40

.po file??? that does not work on betawiki
.po is a bilingual container format used in Open Source localizations and does not easily allow for the creation of tms - well in the meantime there are some tools that help you to create a tmx out of a .po, but you still remain with that stupid format
if any: it is needed in .php (that is the original source format they probably had before creating .po
why does the OS world only know .po? it is the worst you can work with, why don't they come down to real translation standards? getting a huge hick-up ...
Yury Tarasievich guest
25 March 2007 15:08

We actually have a .php file, of the those kind the MediaWiki produces in PHP link in Special:Allmessages. Partially translated, my guess would be over 50%. Tested on local MediaWiki installation and seems to look and work okay.
I seem to never get an email answer these days in predictable timeframe, so I'm now taking the liberty to send the inital throw-in of the php to *all* of you (50k in mime'd archive).
*I apologize for that profoundly*, but it seems like a surest way to facilitate the ball rolling. So, no hard feelings because of that spammer-like behaviour, okay? Thanks!

Archival and transparency, scope, and processing method

This is an email discussion about archival and transparency, scope, and processing method. A consensus was reached on scope and processing method, and everyone except GerardM agreed to public archival.

Jesse Plamondon-Willard (Pathoschild)
03 March 2007 14:13

Hello,
There are a few points I'd like to clarify.
1. Archival and transparency.
Our charter<1> states that the whole set of our activities are public, but virtually all discussion is through private email or on IRC. I would like to archive our email discussions on the subcommittee wiki. Does anyone object to this?
2. Scope.
Re-reading our charter, we do not have the explicit authority to make decisions (although it is implied: "a clear step-by-step policy [...] for evaluating the feasibility of new language wikis with an automated procedure for project development"). Should we forward every request to the board, regardless of how unfeasible the request is? Or does the charter suggest some leeway in filtering requests, and we should only forward feasible requests?
3. Processing method.
How will we process requests? There are currently 39 open requests, of which two are in the test project phase. One method would be to propose decisions through email, and if there are no objections after a delay (perhaps 24 hours) the decisions are implemented and the next batch is proposed. If anyone objects but needs more time to respond, they can just say something like "I object to the second proposal; I'll explain later, no time now".
<1> charter: http://langcom.wikimedia.org/wiki/Main_Page#Subcommittee_charter
Berto 'd Sera
03 March 2007 14:29

Hi Jesse!

1. Archival and transparency.

Okay for me :)

> 2. Scope.
> Should we forward every request to the board,

No. It will take ages to deliver a new wiki even if filter them. And if we do not what exactly is our function? Our archives are public, none can say we produce wiki-desaparecidos :) But we exist to make sure that requests are well-formed, so it should be us to decide what is well-formed and what is not.

3. Processing method.
>of which two are in the test project phase.

You mean in the incubator? If so it's only two. No work in the incubator = no wiki. There is no point in making requests when it's not clear whether the project has the strenght it takes to become a wiki.

> "I object to the second proposal; I'll explain later, no time now".

I object in principle to anyone not having:
- an ISO 639 code (but I'm willing to help to get one, if they complain with our definitions)
- a decent work done (with no robots) in the incubator. Say 5 users and 500 articles or whatever we stated in the official policy (can't remember now), a fully translated UI and a basic policy (at least the "Neutral educational content" clause should be there in a clear form).
I say "no robots" because it's unfair. This way a geek with 3 native speakers can have a wiki in two days while a community of 2 million people from Africa would wait for ages. A community is not made by python slaves, it's made by living people. Once they have a wiki I'll happily spend my time to help them with robots, but that's AFTER they got approved as real humans.
Jesse Plamondon-Willard (Pathoschild)
03 March 2007 14:54

Hello Berto 'd Sèra,
The policy requires a code before a proposal can be approved. There are some cases where a language deserves a code but doesn't have one yet; it would be perfect if you can help users get one.
There's no explicit requirements in the policy that define a 'successful' test project, because that is best left to judgment. Trying to define every case where it is successful or not would be difficult and wouldn't work anyway. It would be a good idea to write some basic guidelines for successful test projects, but we shouldn't codify them as inflexible requirements.
For example, 500 articles and ten users is a failure if there are ten bot accounts automatically importing text; on the other hand, it's somewhat successful if the proposal is *supposed* to be mainly bot-edited, as with some of the wikis that automatically convert text from another wiki's writing system.
In general, I agree that we want a human community, not an army of bots. If there are both, all the better— bots are excellent tools.
Jon Harald Søby
03 March 2007 20:15

On 3/3/07, Jesse Martin wrote:
> Hello,
>
> There are a few points I'd like to clarify.
>
> 1. Archival and transparency.
> Our charter<1> states that the whole set of our activities are public,
> but virtually all discussion is through private email or on IRC. I
> would like to archive our email discussions on the subcommittee wiki.
> Does anyone object to this?

I have no objections. However, I think archiving would be more practical if we got our own mailing list; this would also make communication easier (pressing just "reply" instead of "reply to all" ;-).

> 2. Scope.
> Re-reading our charter, we do not have the explicit authority to make
> decisions (although it is implied: "a clear step-by-step policy [...]
> for evaluating the feasibility of new language wikis with an automated
> procedure for project development"). Should we forward every request
> to the board, regardless of how unfeasible the request is? Or does the
> charter suggest some leeway in filtering requests, and we should only
> forward feasible requests?

I believe the board has has more important things to do than to judge on language matters, and frankly, I think it doesn't fall within the board's scope - what language editions exist or don't exist of Wikipedia really has little with the Wikimedia Foundation itself. But of course, this is up to the board itself - we should probably ask.

> 3. Processing method.
> How will we process requests? There are currently 39 open requests, of
> which two are in the test project phase. One method would be to
> propose decisions through email, and if there are no objections after
> a delay (perhaps 24 hours) the decisions are implemented and the next
> batch is proposed. If anyone objects but needs more time to respond,
> they can just say something like "I object to the second proposal;
> I'll explain later, no time now".

The e-mail approach would be easier with a mailing list; each new language proposal should have its own thread, perhaps marked in a specific manner (e.g. with a [new] tag or something). The delay should be considerably longer than 24 hours, however, I'm thinking 1 week - 10 days.
Jesse Plamondon-Willard (Pathoschild)
03 March 2007 20:22

Hello,
I agree on all points. If the delay is longer, though, we'll need to consider several requests simultaneously.
GerardM
04 March 2007 11:33

<this user has not agreed to public archival.>
Berto 'd Sera
04 March 2007 15:42

Hoi!
<this text is quoted from a user who has not agreed to public archival.>
Yes. My impression is that people simply don't give a damn about it. Or maybe they are afraid to speak a clear word about it. It takes 5 minutes to see the material and say yes/no. Why on earth is WMF becoming more twisted than the former Central Committee of the Soviet Communist Party!?
<this text is quoted from a user who has not agreed to public archival.>
Yes. We need real data to make a decision, not just the usual list of names that may be fully invented (anyone can call up friends to register as native speakers). Let's see real stuff befre we spend real words. But once we have it let's be quick, or the people will be upset.
BTW, if I wanted everyone upset against this Commitee I'd do exactly what the Board is doing. I'd have everything paralyzed, and let the Committee be the escape goat... Maybe for some people this is a very good reason for them to become REAL SLOW :) Childish, isn't it?

Localization

This was a March 2007 email discussion about localization. No consensus was reached.

Gerard Meijssen
05 March 2007 08:36

<this user has not agreed to public archival.>
Berto 'd Sera
05 March 2007 08:56

Hoi!
<this text is quoted from a user who has not agreed to public archival.>
I support this. One question, are the people aware of the need for localization? Maybe we should add it in the request template? We are close to a 100% of negative cases; maybe we have a communication problem.
Gerard Meijssen
05 March 2007 09:19

<this user has not agreed to public archival.>
Jesse Plamondon-Willard (Pathoschild)
05 March 2007 12:59

Hello,
I strongly disagree. Localization is best done by the communities that would benefit from it. If technically necessary, the community can start with an English interface and translate it live; these translations can then be added to the localization files for future projects. It is easy to localize live with Special:Allmessages. If we must have a fully localized interface before starting, we can make a wiki page like Special:Allmessages on the incubator that users can translate.
Denying requests on such a minor technicality will be extremely aggravating for users who have already been waiting nearly half a year for the subcommittee to make minor changes to the existing policy. Further, this will significantly slow localization efforts, since there will be no community benefiting from it and no easy method to do so.
GerardM
05 March 2007 13:04

<this user has not agreed to public archival.>
Jesse Plamondon-Willard (Pathoschild)
05 March 2007 13:38

Hello GerardM,
Sorry if I misunderstood. In that case we don't want to *reject* requests without localization, we want to *conditionally approve* them until they localize. I'll discuss with the incubator community to find a way to simplify this until the betawiki functionality is available.
Gerard Meijssen
05 March 2007 14:04

<this user has not agreed to public archival.>
Jesse Plamondon-Willard (Pathoschild)
05 March 2007 14:13

Hello,
I think you might be misunderstanding what I mean by 'conditionally approve'. As described by the language proposal policy<http://meta.wikimedia.org/wiki/WM:LPP#Conditional_approval>, this allows us to decide that an edition in that language is feasible, while refusing to approve the project until other criteria are met. In most cases, we would conditionally approve until a viable test project is formed with sufficient localization.
Conditional approval means a test project on incubator, not the approval of a new wiki. Once the missing criteria have been met, they can submit it to our attention for approval.
Gerard Meijssen
05 March 2007 14:38

<this user has not agreed to public archival.>
Jesse Plamondon-Willard (Pathoschild)
05 March 2007 14:44

Hello,
If you have no better name for it, the 'stinky' terminology will have to suffice. I disagree that any language with a code can be conditionally approved; for example, I will never agree to a United States English Wikipedia, despite it having the standard RFC 4646 code 'en-US'.
GerardM
05 March 2007 14:48

<this user has not agreed to public archival.>
Jesse Plamondon-Willard (Pathoschild)
05 March 2007 14:53

Hello,
A 'go ahead to the Incubator phase' would be misleading; we invite users to create a test project at any time before or after conditional approval. Conditional approval is, indeed, conditional approval; we are essentially saying "This proposal looks good, and we'll approve it if you can just meet this missing criteria." If we are not going to approve them after they meet those criteria, we should obviously not conditionally approve them.
GerardM
05 March 2007 15:00

<this user has not agreed to public archival.>
GerardM
06 March 2007 11:28

<this user has not agreed to public archival.>
Jesse Plamondon-Willard (Pathoschild)
06 March 2007 14:14

Hello,
Have you read the policy at all in the last six months? I don't think the policy can be any clearer about the relevance of voting: "*However, this is not a vote.* The project will be assessed on its linguistic merits and chances of flourishing. Even if there is strong support, the proposal may be denied if there are strong arguments against its creation and insufficiently strong arguments in support as judged by the language subcommittee."
I don't understand what your concern is. If a language itself is suitable but the content is not, conditional approval is given, and the request is only given final approval when the content and community are suitable. If the language itself is not suitable, it is not conditionally approved in the first place.
Gerard Meijssen
06 March 2007 17:23

<this user has not agreed to public archival.>
Jesse Plamondon-Willard (Pathoschild)
07 March 2007 12:36

Hello GerardM,
In that case I misunderstood; I assumed you were criticizing voting in the current process: "<this text is quoted from a user who has not agreed to public archival.>"
The linguistic merits, in my opinion, are inherent in the language itself. Even without being presented any content, it is easy to ascertain from information available that French, Spanish, or Kabyle are suitable languages. In this case, we can immediately approve the language itself, but not create a wiki until the rest of the criteria are met (localization, community, test project, et cetera). The awkward alternative is to force users to hold a new discussion later about the language's suitability if the content is rejected.
Conditionally approving a language does not imply any promise to approve the content in the future. Although the content and community criteria are fluid, the *language* criteria are relatively stable. If a request took a very long time after conditional approval, the language criteria *might* change and we would reject the proposal despite past conditional approval, since the conditions changed. This could be explicitly noted in the policy, if preferable.
If you're entirely against the wording of "conditional approval", perhaps it could be renamed to "language approval" or some such?

Kabyle Wikipedia and localization

This discussion about the request for a Kabyle Wikipedia established localization as a prerequisite and eventually approved the request.

The Kabyle Wikipedia was initially proposed for approval on 23 March 2007, but debate eventually found localization to be requisite. A localization procedure was developed and the MediaWiki interface translated. It was proposed for approval again 08 April 2007, forwarded to the board for final approval 11 April 2007, approved by the board on 25 April 2007, and forwarded to developers.

The board authorized the subcommittee to approve requests without explicit board approval in the future in a spin-off discussion.

Proposal

Jesse Plamondon-Willard (Pathoschild)
23 March 2007 09:59

Hello,
I propose the subcommittee approval of the Kabyle Wikipedia. This language is well-established, has a very wide audience, a large interested community, a unanimous discussion on Meta, and a standard code. In addition, the test project is very successful with over 200 pages and daily activity by multiple users.
Although the project is not localized due to the technical difficulty of localizing without a wiki, the community is more than strong enough to localize with Special:Allmessages once the wiki is set up; there's no reason they would use an English interface. This translation can be added to the localization files by the time a second Kabyle project is approved. This opinion was seconded by Aphaia, member of the translation subcommittee.
- request: http://meta.wikimedia.org/wiki/Requests_for_new_languages/Wikipedia_Kabyle
- test project: http://incubator.wikimedia.org/wiki/Wp/kab
- test activity: http://incubator.wikimedia.org/wiki/Special:Recentchangeslinked/Wp/kab
- Aphaia's comment: http://meta.wikimedia.org/w/index.php?title=Talk:Special_projects_subcommittees/Languages&diff=547693
Bèrto 'd Sèra
23 March 2007 23:10

Hoi!

> the technical difficulty
> of localizing without a wiki,

Pls explain. What's more difficult for them in respect to any other linguistic entity? Why can’t they use Betawiki?
I'm quite against making *any* exception whatsoever. If we allow a wiki without localization (no matter which one and why) we either allow them all or promote the idea that LangCom makes arbitrary decisions based on personal sympathy and internal mafia.
We may mean good but that's the way anyone would interpret such a move. We just canceled all pending applications and keep on hold tens of requests because they miss a localization file, make 1 + 1 and you'll have the meaning that the community will attribute to any single exception...
Do we need that?
Jesse Plamondon-Willard (Pathoschild)
23 March 2007 23:52

Hello,
There is no exception to make; we never agreed to localization as a prerequisite and it is not part of the policy.
BetaWiki is complex to edit and is not affiliated with the Wikimedia Foundation. This method requires that editors register to a third wiki (Meta, Incubator, and Beta-Wiki), explicitly define required preferences, acquire special permission to translate the interface (the "translator group"), and learn to use the translation interface. Every translator must do this; since the only instructions for this complex procedure are in English, bilingual users will need to translate the instructions to the relevant language for those who aren't. Furthermore, users cannot translate important wiki-based pages such as the sidebar.
On the other hand, translating live consists of going to "Special:Allmessages", clicking a redlink, and filling in the translation.
If BetaWiki were merged into the Incubator as an extension, it would be much more workable; users could translate the entire wiki simultaneously. However, it is not very workable as a separate, unaffiliated, complex procedure on a personal test wiki.
Bèrto 'd Sèra
24 March 2007 12:51

Hoi!
Okay, let's try and see some light in the tunnel :)
1) I maintain PMS in betawiki myself and made its first interface by editing AllMessages myself, single-handed. It takes but a couple of days in all. BTW, I use a 16kbits dialup on a very aged soviet telephone line. You don't need a broadband connection to use goodwill and there's nothing complex in reading an expression and writing an equivalent in your native language. If even the translator cannot understand an expression, then HOW do we expect a not bilingual community to be able to use it??????????
2) Mandatory localization SHOULD be in the policy (it was in the draft we first published and approved, if this was changed I never voted to allow its deletion). I'll never give green light to a project that is not localized (just as won't accept bots on the incubator to fake a community where there's none).
3) The fact that betawiki is outside wmf is irrelevant. Volunteers aren't part of wmf either, and we don't feel disgusted by what they do. If we were to accept only internal stuff then no public translation interface should be available, we would have the whole job done by paid translators in Micro$oft $tyle. But that's not our case.
4) It's 100% true that betawiki misses the extensions, yet it's just a couple of things (like special chars) we are talking about, and the sidebar, which is better decided by community discussion anyway. There's nothing weird in using betawiki (try and make a PO translation for a linux interface) and ALL translation processes (and decisional life at meta level) are documented in english anyway.
5) A community that has not at least one user who is fluent in english and willing to represent it at meta-level is going to become autistic. We may not like it, but it's a PLAIN FACT. We have more than enough political wikies maintained by hallucinated sects to deal with.
6) I can't see what's the problem in having one more user in another wiki, people do not pay to register a user in Betawiki, afaik. If we have a procedural problem with Betawiki (like giving people a translator role) we should address it as general procedural problem, not as an act of delicacy towards langcode ZXX. Rules are rules; we cannot act as emperors whose thumbs may save a life or terminate it.
8) I take it that for smaller linguistic communities this may well be the first impact with the technology. Yet this didn't keep those users to show up in the incubator. I'm myself from a linguistic community of less than 2 millions native speakers (mostly elderly people) with a 2% alphabetization rate. We could make it, they can make it.
9) I will strongly support any community action directed to help people learn. It's not just empty words. I have almost no spare time, but if needed just give them my email and tell them to make any request for explanation they may need at any time. I'll be happy to help with minimal requirements, but I won’t change my vote to make anyone's life easier, including mine.
In short, I officially oppose the creation of ANY unlocalized wiki. You can record this opposition vote as unchangeable for any further such request.
Jesse Plamondon-Willard (Pathoschild)
24 March 2007 01:11

Hello,
As far as I can tell, none of the policy drafts at <http://langcom.wikimedia.org/wiki/Language_proposal_policy> have ever required localization. What do the other subcommittee members think of requiring full localization before approval?
Bèrto 'd Sèra
24 March 2007 01:15

Hoi again,
Jesse , pls don't take my position as a personal will to blunt lock-gates against any new project. As a matter of fact I'm spending a huge number of hours in translating wikipedia articles in rare slavic languages that are full of political assertions that (if translated and published) would *seriously* damage our public image.
You don't want donors to know that their donations are used to publish revisionist history, a blatant usage of terms that equivalent to *nigger* in their racial derogatory value, etc, etc. So what many of us do is keeping a monitoring eye on as many languages as possible and eventually get to the point in which some Committee will decide of the most dangerous events.
It's quite true that having a real community is not a warranty about the neutrality of a wiki, yet as a matter of fact most of the weirdest wikies happen to be managed by a couple of overheated extremists. Maybe if we had a required a wider number of users for a starting edition this problem would have been reduced.
If we want users to take wikipedia seriously we must not make a toy of it since the very start. I'm positive you just want to help people, yet there is no good thing in life that one can get for free. Valuable things always come from hard work and a good wiki is no exception.
Jesse Plamondon-Willard (Pathoschild)
24 March 2007 01:22

Hello,
Did you mean to send that last message to the whole subcommittee or only to me?
I agree with what you're saying; those are the problems I wanted to prevent when I wrote the policy draft a few months ago, and it is one of the reasons we require a successful test project before approval. However, I don't think localization of the interface itself before approval rather than after will affect the viability of the communities or the veracity of the content.
Bèrto 'd Sèra
24 March 2007 13:35

Hoi!
Yes, it was for all. I'm getting sleepy (8.35 am on the eastern front) and I simply landed on the wrong button :) I wrote a number of things about localization for small communities here: http://eng.i-iter.org/making-new-semantic-domain
As a matter of fact making a wiki interface is "inventing a semantic domain". That cannot be done by a lot of concurrent hands because it will result into a unusable jam. A community should really choose one or more interface editors and it should discuss about the language they "create".
Being immediately understandable to a native speaker who never really used technology is 90% of the marketing behind a small language wiki. We had our first 5 nation-wide press articles just because our literal translation of the term WEB sounded funny (actually I just picked it up from a friend as I found it funny, too). Our term "Ragnà" (web) prompted the first printed appearance of text in the piemontese language on the national press in 150 years, because then they moved to discuss our GNU license, etc etc.
We keep having press coverage mainly because the italian local languages do translate those english words that the italian interface imported as unchanged. It's not just a small procedural step we talk about, interface language is a big asset for a wiki, maybe the biggest asset a wiki can have because it defines how usable (or cryptic) that wiki will be.
Gerard Meijssen (GerardM)
24 March 2007 01:57

<this user has not agreed to public archival.>
Sabine Cretella
25 March 2007 13:32

Hi, I just came back home: well localization is the basics ... and for Neapolitan I still have a hard time to get people to localize stuff in the right place: so new projects should avoid these problem in a first place. If they learn to maintain the localization directly on betawiki from the beginning they will always do it - if you allow for anything else ... you get projects that even after half a year are not localized. See the so-called Tarantino wikipedia: http://roa-tara.wikipedia.org/wiki/Pagene_Prengep%C3%A1le
If they have time to write the articles they should also have time to do the localization ... or am I wrong?
Having the localization done before a wiki is opened was always the goal.
Sorry for being short - have to put things away.

Localization procedure

Jesse Plamondon-Willard (Pathoschild)
27 March 2007 21:38

Hello,
There seems to be a consensus in favour of requiring localization, so I'll accept it. I've implemented it as a requirement in the language proposal policy. I thus propose the following procedure to streamline and simplify the Kabyle localization. This will be a good test case for future localization efforts.
1. Set up a specific section on the request discussion page to answer questions, provide updates, and coordinate localization.
2. Contact every user who has expressed an interest in contributing of this effort.
3. Establish a group of trusted users who will coordinate the localization in the Kabyle community and form the initial group of administrators. Doing this will allow users to begin the wiki prepared, minimize conflict, and let users work together with the future administrators to ensure that they are a good choice *before* complex and conflictive desysop'ing is the only appeal.
4. Set up a small number of subcommittee members to take official charge of this effort. This ensures that [a] guidance is always available, where normally subcommittee members might be busy elsewhere or forget about the effort, [b] it is easy for editors to find help, and [c] users are sure of our support and interest. Other subcommittee members would help as much as they desired, of course, but these few members would make it a point to be available as much as possible.
What do you think of this process?
Jon Harald Søby
28 March 2007 12:02

Well, after reading the slaughtering thread, I think there are some good arguments against demanding a localisation beforehand. Localisation is very hard work, and even I, who have been involved with wikis for more than two years now, in a lot of ways (as common user, anon, sysop, steward, bot operator), don't even know what some of the messages in "core" on BetaWiki actually mean, and have never encountered them.
What I suggest is that we make a list of the real core messages, perhaps around a hundred of them or so. What I suggest is that the main page, and all pages linked from it in the menus, etc, are to appear fully translated to begin with. Then, when they start the Wikipedia, they can translate the rest, if they feel like it. But it shouldn't be a requirement to have everything translated. (Not even Norwegian, which has more than 100 000 articles, have a fully translated MediaWiki message system; most of what's untranslated are those stupid and pointless Exif- messages, though, while the rest is translated.)
Gerard Meijssen (GerardM)
28 March 2007 04:24

<this user has not agreed to public archival.>
Jesse Plamondon-Willard (Pathoschild)
28 March 2007 09:04

Hello GerardM,
I proposed the selection of a small number of editors based on the advice of Bèrto 'd Sèra earlier in this discussion:

"As a matter of fact making a wiki interface is "inventing a semantic domain". That cannot be done by a lot of concurrent hands because it will result into a unusable jam. A community should really choose one or more interface editors and it should discuss about the language they "create"."

Do you disagree with this advice?
Bèrto 'd Sèra
28 March 2007 10:07

<this block of text is marked as private.>
EXIF msgs... they are pure bullshit, I'm lucky me and my dad have always played with cameras, but I really hated them when I translated them :)))) I'm also positive 100% translations can't be made (new messages appear/get changed almost every day). It's one more reason to have someone keeping a constant eye on the UI.
At least all commands should be translated (and the copyright statement, too, because it's a contract and end-users have the right to understand what they implicitly sign), but whether you translate EXIF msgs or the like of it IMHO is largely a matter of choice.
This should be a process by which a community "configures" its own wiki and learns how a wiki works and what admins are supposed to do with it. My best option would be an incubator mailing-list, in which translators and would-be admins could get to know each other and help each other.
Anyway... what if we stop talking theory and we start an experiment? We can use it to document the process and later make adjustments while we learn from a case of study. Let's begin this Kabyle translation, so we can address real problems as they come.
Jesse Plamondon-Willard (Pathoschild)
28 March 2007 19:56

Hello,
I agree; localizing every last message is unnecessary. Perhaps we should determine the files to be localized in discussion with the Kabyle community; this collaboration will simplify the process for us, improve the accuracy and quality of our selection, and the involvement of the waiting community will alleviate impatience.
GerardM has stated that all users should translate the interface simultaneously; Berto has stated that they should select a few users to work on the interface. I prefer the latter, as I proposed above. Any other opinions? Are there any objections otherwise to my above proposal (contact the users, centralize discussion and collaboration)?
Gerard Meijssen (GerardM)
24 March 2007 01:35

<this user has not agreed to public archival.>
Bèrto 'd Sèra
29 March 2007 09:21

Hoi!
LOLOL Gerard, I didn’t expect a quote from Simon & Garfunkel J
Okay, let’s look for a convergence point:
1. I’d like to have an interface in the community for us to be able to remain in contact with them while they localize (and not to give them the impression that we simply “forgot about them”).
2. Nominating an interface is one more request and can sound as a limit for the community
I’d say we can start with no fixed organization, but just an informal interface. My point is that most of what we will fix as a “procedure” should come from practical experience, and it should be some sort of “endless blog” from the people who start-up the communities (not us, that is, but the native speakers involved in making new wikies). In the end it’s a sort of “entrance fee” we request. People get a wiki and pay for it by delivering a new localization for mediawiki software.
Gerard Meijssen (GerardM)
29 March 2007 09:42

<this user has not agreed to public archival.>
Bèrto 'd Sèra
29 March 2007 09:49

Hoi,
Sorry, what code are we talking about?
Gerard Meijssen (GerardM)
29 March 2007 11:32

<this user has not agreed to public archival.>
Jesse Plamondon-Willard (Pathoschild)
29 March 2007 12:33

Hello,
There doesn't seem to be any opposition to centralizing discussion at <http://meta.wikimedia.org/wiki/Talk:Requests_for_new_languages/Wikipedia_Kabyle>. This is a pretty logical choice, so there's no need to nominate or vote on it, nor establish any codified procedure.
I don't oppose a free-for-all localization; this will be a good chance for the users to get to work together, and mistakes can easily be corrected by other editors. Berto, do you oppose this? There doesn't seem to be any support for assigning subcommittee members to help, so I'll just make sure to watch the discussion to make sure all their questions are answered.
If there's no opposition to a loose collaborative method (centralized discussion, free-for-all localization), I will announce that and get it going as soon as possible.
Gerard Meijssen (GerardM)
29 March 2007 12:43

<this user has not agreed to public archival.>
Bèrto 'd Sèra
29 March 2007 14:24

Hoi !
That’s good news J
Jesse Plamondon-Willard (Pathoschild)
29 March 2007 14:34

Hello,
Alright then. If there's no opposition to the adjusted proposal, we'll begin tomorrow. This isn't a codified procedure, just a way we can proceed with the Kabyle Wikipedia.
1. Set up the request discussion page to answer questions, provide updates, and coordinate localization.
2. Contact every user who has expressed an interest in contributing of this effort.
3. Help any interested user begin localizing.
Bèrto 'd Sèra
29 March 2007 16:41

Hoi!
Okay for me, I would add a sort "contact structure". I mean, we speak different languages, I just started correspondence with the Ingush because we have a common russian, maybe there are other people who can volunteer their languages with other fallbacks.
The further we get from the West the more important it will be to be able to deliver assistance in non-english form.
Jesse Plamondon-Willard (Pathoschild)
01 April 2007 05:40

Hello,
With no opposition, I've started the localization process and mentioned it in the relevant mailing list discussion.
- localization discussion: http://meta.wikimedia.org/wiki/Talk:Requests_for_new_languages/Wikipedia_Kabyle
- list mention: http://lists.wikimedia.org/pipermail/foundation-l/2007-April/028740.html

Second proposal

Note: The discussion was partially split to "Authority to approve a wiki" (April 2007).

Jesse Plamondon-Willard (Pathoschild)
08 April 2007 15:01

Hello,
I propose the approval of the Kabyle Wikipedia. The community has currently localized 75% of the interface, or nearly 100% excluding files marked as unnecessary and the administrator interface (which will be translated by the upcoming Kabyle Wiktionary community). It is currently conditionally approved.
I'm discussing with Nikerabbit and the Kabyle community to work out the last few details before the translations are committed.
Jesse Plamondon-Willard (Pathoschild)
12 April 2007 22:30

Hello,
Erik told me on IRC that it will take him a few days to catch up with email.
Erik Möller (Eloquence) Executive Secretary
19 April 2007 21:52

<this user has not agreed to public archival.>
Erik Möller (Eloquence) Executive Secretary
25 April 2007 15:17

<this user has not agreed to public archival.>
Jesse Plamondon-Willard (Pathoschild)
25 April 2007 17:27

Hello,
I've submitted a request on bugzilla <http://bugzilla.wikimedia.org/show_bug.cgi?id=9699> and poked JeLuF.
Jon Harald Søby
08 May 2007 23:16

Just for procedural purposes, the Kabyle Wikipedia has now been created.
http://kab.wikipedia.org/

Private mailing list?

See also "Subcommittee mailing list" (April 2007).

This was an email discussion about the creation of a private mailing list. Consensus was reached to do so, and it was created in April 2007.

Bèrto 'd Sèra
24 March 2007 01:52

Hoi!
What if we set up a private mailing list for such discussions? It's a bore when you always have to verify that you have copied an answer to all involved parties.
Bèrto ‘d Sèra
Gerard Meijssen (GerardM)
24 March 2007 06:10

<this user has not agreed to public archival.>
Jon Harald Søby
24 March 2007 15:49

We could set up a private mailing list, that should be no problem. It makes it a lot easier to keep track of discussions.
Jesse Plamondon-Willard (Pathoschild)
25 March 2007 01:04

Hello,
I see no problem with a publicly-readable mailing list; all our comments except GerardM's are publicly archived. Even some of the third parties who emailed us have agreed to public archival.

Private blog post by a subcommittee member

This is an email discussion about a private blog post by a member of the subcommittee. It was posted with no objection.

Bèrto 'd Sèra
25 March 2007 00:50

Hoi!
I’m thinking to post a blog on en.planet about these interface localization thing. I’ll post the text here before publishing, anyway. Although this will be just a private post of mine it’s important that we don’t start giving out a schizophrenic message. My impression is that apart from publishing policies we also need to explain things in human readable terms.
Let me know if anyone opposes, because in that case I won’t spend my time in writing on the subject.
Jesse Plamondon-Willard (Pathoschild)
25 March 2007 00:57

Hello,
That's fine by me, particularly since it's not posted as a message by the subcommittee. All our discussions (except GerardM's messages) are publicly archived, so we have nothing to hide. :)
Bèrto 'd Sèra
25 March 2007 04:32

Hoi !
That’s the text I’ll publish on my blog, if no objection is made (the « other post » quoted is the one I mentioned yesterday)
You don’t let a baby out of the incubator until you are sure it can survive

In a simple, perfect world it wouldn’t take much to have a new wiki: say we would have a form and an automated script. Users X wishing to open a wiki written in the ZXX linguistic entity would simply choose the ZXX code form a list and click a Create wiki button. After all, setting up a wiki is but an administrative job, the sort of things that any host does by automated scripting directly from a cpanel. So why are wikies THIS darn primitive? Why do we need to make requests, have incubators, translate interfaces… is it just a way to keep people from having a wiki or what?
A first easy answer is that a wiki is not a private home page. Webhosting is easy because you pay your money and then the host basically wants to hear from you just one more time: on renewal. So they do whatever they can to get rid of everyone asap without needing to pay for human personnel. Sometimes it’s frustrating (we all had a problem that lacked qualified assistance in out life), but it’s quite logical.
WMF is not selling anything, though. We are providing a free service. This means that WMF first receives money from donors to produce a certain service (an encyclopedia) and then chooses on how these funds will be spent. So opening a wiki is an act that involves responsibility before donors, who (together with our volunteers) can be pretty much described as wikipedia’s “taxpayers”. A simple automated procedure cannot be used, because there is a need for a project to be evaluated before saying that it’s okay to invest resources on it.
Once we need to make a scrutiny, we are immediately confronted with the same old NPOV problem that marks the whole wikipedia life. We need a decision making procedure that will be fair to everyone and not just based on personal impressions/moods/etc. In the past we had a procedure made of a so called “public vote”. This worked quite well until only major linguistic entities were involved, but as soon as minor entities started to appear the number of pure political conflicts just skyrocketed.
Everyone who’s been reading meta remembers a good number of cases in which crazy mobs insulted each other for months. Socket puppetry and bogus voting were the most common events. It soon became self-evident that even the most NPOV wikipedian can go nuts when he deals with linguistic problems that are in some way connected with his/her own direct political environment. The system was obviously not working; we had to find a way that would keep politics off the process. LangCom was the answer.
Nowadays many people lament their requests being held for “mysterious reasons”. There is no mystery, though. LangCom publishes its discussions at http://langcom.wikimedia.org/wiki/Category:Archive . The idea behind this post is that (as always when a transition in methodology happens) there is no such thing as an excess of information. Maybe someone will disagree with what we say in our proceedings, but it’s in anyway better to have a clear discussion on a given point than having people dream of weird conspiracy theories.
So, the current situation is:
1. All requests made on an older standard have been closed (which does NOT mean they were denied, we simply require another standard, i.e. they should be resubmitted asap.
2. Once a given request has met the minimum levels you get an incubator in your language (voting/flaming is NOT a level, we simply do NOT care about how many votes you get, oppositions are simply ignored unless they have a firm technical base, no political argument can be considered, “dialect” argument included, you do need a minimum number of native speakers, though)
3. In this incubator you form a community and translate your interface, this is what really gets evaluated, that is, what REAL results your project can give to wmf.
So, the main things you should know are:
1. Flaming won’t help a new project (and it won’t even damage it, it will simply be ignored as “irrelevant”);
2. Community building is a BASIC step of the incubator process: there is no time limit, nobody is asked to deliver within X days or die, on the opposite, people are requested to grow to a decent organization level before being granted an independent domain, if it takes long, then be it. The incubator is what the name says, if we meant it to be a limbo, we would call it limbo.wikimedia.org, but we call it incubator, and that’s what it is;
3. A full translation of the user interface IS a strict prerequisite from many Committee members (including me), so you can expect NO as an answer any time a project requires a domain before having produced a localization file.
This latter point probably needs some explanation. Many people believe that “you can just make the translation later on”. This was definitely true as far as major languages were concerned, but how many major languages still miss a wiki? You are right, the answer is “none”.
Now put this element together with the fact that right in these day the “Byelorussian syndrome” finally reached a conclusion and the whole matter originated by allowing people to produce “just any interface”. You are probably not familiar with the “Byelorussian syndrome”, though, so I’ll take a minute to explain.
Our planet is filled up with governments and people have mixed opinions about them (I personally cannot stand any of them). As a result a lot of political statements are produced. In this case, there is a group (called NN by the journal they publish) who opposes the current Byelorussian President, Mr. Lukashenko. Actually it’s many such groups (as with any president on earth), but this one has a distinct peculiarity: they work on the “Byelorussian identity” by working on the structure of the Byelorussian language.
While their linguistic operation probably has a number of merits, as a matter of fact the resulting language is NOT what described by a BE ISO code. Moreover, the resulting language is not a living language, it is a construct made with a political aim in mind. Now suppose a number of those who believe that George Bush “stole” the last American elections made up an interface based on Mark Twain’s language like “a body’s gwyne-a-edit th’artkl-hear”. You may probably resort to old Lil’ Abner graphics and make it a very fortunate interface but the fact remains a fact: this is NOT an English language interface.
So how could we deliver a wiki made in a constructed language in the first place? Easy, we simply did not check the language being used. We allowed an “it will happen later anyway” policy and the result was an endless war, plus a wiki in an official state language (Byelorussian) that has lived thrice as much as my native PMS wiki and managed to make ~6.000 articles against our almost 5.000 in less than a year (and we are less than 2 million people with a 2% alphabetization rate). So there ARE reasons why we really want to check that the ISO code a project declares is going to be used as such.
Another reason is more practical, it’s called marketing. For most small minor linguistic entities a wiki is a debut in the IT arena. If you let a crowd of casual translators make up an interface “as time goes by” you’ll end up with the same term being translated in an endless variety of ways. As a matter of fact, building a technical vocabulary from scratch requires tact, co-ordination and some thought (see this other post for a number of reflections on how to build an interface). We all tend to undervalue this, because we all have a fallback language (English). But what if the community has no immediate fallback language?
You don’t need to reach the Amazonas for that, my own linguistic community is made up of two main geographical branches, one of which lives in Argentina in the so-called Pampa Gringa and the other in Piedmont, Western Alps (a lesser third lives in North America, but it’s almost extinct, from a linguistic POV). So what fallback language can we use? None, that’s it. And the further we get from western cultures, the more potential communities will have this problem. A fully translated user interface is not just a political correctness indicator. It’s a usability factor. How many articles would you see on en.wiki if its user interface looked like that of fa.wikipedia.org? None, or almost none…
The user interface is also the one and only thing that can get the press attention on a new wiki. No new wiki is going to come out from the incubator with 100 featured articles, this is just obvious. So what do you expect local media to talk about? Unless they can speak about the way in which you translated “mouse” and “web” they will only say “now we have Zxx.wiki, too. We all hope that someday it will be interesting to read it”. Not what you’d call enthusiasm, but on the other hand what can an honest journalist write?? Your wiki IS empty, isn’t it?
A nice interface and a nice main page have an extremely relevant impact on a project’s capability to attract traffic. It’s no secret that you need all the press you can get to make up a community, and you won’t get this press unless you give the journalists something they can write about. Our picking up common PMS street slang in our interface prompted the publication of the first Piemontese text in 150 years (at national level, we obviously always published for ourselves, but the involved numbers were MUCH smaller).
Just because of a few funny words we had hundred of thousands of people informed about our existence just 2 weeks after opening, when we had less than 100 articles. The tide hasn’t gone down, yet. Articles at national level keep appearing and they ALL talk about user interfaces first (plus invented traffic numbers, journalists cannot accept the fact that there are no real traffic data in wmf, so they make tem up themselves). These articles speak about all Italian minor linguistic entities as a collective category and bring traffic to every one of us, but they ALL center on user interfaces.
In the beginning some people in our wikies considered such behavior as offensive. Journalists sort of smiled about us. So what? Let them smile, as long as they talk about you it’s just added traffic you get and more helping hands for your community. Moreover, there’s nothing wrong in speaking about the language used. Actually it’s the opposite, since the one and only difference among wikies is (or should be) restricted to the language in which they are written. From any other point of view a wiki should simply be an encyclopedia.
I hope it’s now a bit clearer that we do not keep any project in hold. We simply care for projects to be capable to be successful wikies, and that’s it. You don’t let a baby out of the incubator until you are sure it can survive. Because if you do you are a killer.
Jesse Plamondon-Willard (Pathoschild)
25 March 2007 18:27

Hello,
I would prefer a disclaimer somewhere noting that this isn't a message by the entire subcommittee, but otherwise it looks fine. Do you have any problem with archiving that, or would you prefer to publish it on your blog first?
Bèrto 'd Sèra
26 March 2007 00:36

Hoi!
I added the disclaimer since the very start :) I am used to take my own individual responsibilities in the clearest possible way :)
It's published here: http://eng.i-iter.org/you-don-t-let-baby-out-incubator-until-you-are-sure-he-she-can-survive
It's repeated on en.planet and a number of other blogs. Not that it gets even 15% of the traffic more general topics get, which is in itself a indicator of "quiet state" for the issue. There is no general uprising in Wiki St and we can work for a good resolution that will suit all and everybody.
Yet while waiting for a Board's statement would be formally correct it's going to be risky if we keep people waiting until forever while the Board does not have time for us. Let's request a mailing list and start the jobs.
Gerard Meijssen (GerardM)
26 March 2007 06:42

<this user has not agreed to public archival.>

[private] Lack of progress and how to begin processing requests

[private] Sensitive wikis

Archival permission

This is an email request to allow public archival, which was accepted.

Jesse Plamondon-Willard (Pathoschild)
TO Yury Tarasievich
24 March 2007 12:19

Hello Yury Tarasievich,
We regularly copy emails to <http://langcom.wikimedia.org/wiki/Archives> for transparency and to keep users up to date. Do you object to archiving your messages to the subcommittee in this way? If you would prefer to keep your messages private, your messages and derived quotations will not be archived.
Yury Tarasievich guest
TO Jesse Plamondon-Willard
24 March 2007 03:52

That's just as well. I have nothing to hide or to be ashamed of in the complete course of my email communication on this issue. Please do as suggested.
Jesse Plamondon-Willard (Pathoschild)
TO Yury Tarasievich
24 March 2007 16:06

Thank you.