Mailing List Archive

On Sun, Oct 19, 2008 at 12:48 AM, Crazy Lover
<always_yours.forever@yahoo.com> wrote:
> I add (In language Proposal policy - communiy draft) a clause is for languages with
> active wikis, but which Code has been invented: voro (fiu-vro), tarantino (roa-tara), Cantonese (zh-yue), min nan (zh-min-nan) , etc.
>
> For new proposal those will continue using the same
> invented code that are using.
>
> The problem: Imagine that they will
> use different codes [.when get a ISO code or if they have: Min nan (nan), Cantonese (yue)] for new projects, the technical chaos that would
> occur.

This need not be a problem. Just create an HTML redirect, and let the
thing resolve itself in time. We have already had some moves (minnan
to zh-min-nan, no to nb, perhaps also dk to da?) without problems.



--
André Engels, andreengels@gmail.com
_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Crazy Lover wrote:
> I add (In language Proposal policy - communiy draft) a clause is for
> languages with active wikis, but which Code has been invented: voro
> (fiu-vro), tarantino (roa-tara), Cantonese (zh-yue), min nan
> (zh-min-nan) , etc.

zh-min-nan was indeed invented by a Wikipedian, but he went to the trouble
of getting it approved by IANA, in 2001:

http://www.iana.org/assignments/lang-tags/zh-min-nan

We have to give him credit for that.

zh-yue is also an approved RFC 4646 language tag. The other two you
mention really are invented. Voro, fiu-vro, appears to have been made
obsolete by the ISO 639-3 code "est", so the wiki can be moved now.
Tarantino, roa-tara, doesn't appear to have any valid RFC 4646 code, so we
should probably apply to IANA to create one. There is an ISO 3166-2 region
code for Taranto (IT-TA), but RFC 4646 doesn't seem to allow them.

-- Tim Starling


_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Hoi,
Really problematic are codes like the one used for Alsation; the "als" code.
This code is according to the standard to be used by Tosk Albanian while we
use it for "Alsatian". This is not acceptable for what we currently do,
making it compulsory for future new projects is not acceptable either.
Projects like these should be renamed as they are squatting ligitimate codes
for ligitimate languages.
Thanks,
GerardM

On Sun, Oct 19, 2008 at 12:48 AM, Crazy Lover <
always_yours.forever@yahoo.com> wrote:

> I add (In language Proposal policy - communiy draft) a clause is for
> languages with
> active wikis, but which Code has been invented: voro (fiu-vro), tarantino
> (roa-tara), Cantonese (zh-yue), min nan (zh-min-nan) , etc.
>
> For new proposal those will continue using the same
> invented code that are using.
>
> The problem: Imagine that they will
> use different codes [.when get a ISO code or if they have: Min nan (nan),
> Cantonese (yue)] for new projects, the technical chaos that would
> occur.
>
> Please check it out:
>
>
> http://meta.wikimedia.org/wiki/Meta:Language_proposal_policy/Community_draft
>
> C.m.l.
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> _______________________________________________
> foundation-l mailing list
> foundation-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>
_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

On Sun, Oct 19, 2008 at 1:39 AM, Gerard Meijssen
<gerard.meijssen@gmail.com>wrote:

> Hoi,
> Really problematic are codes like the one used for Alsation; the "als"
> code.
> This code is according to the standard to be used by Tosk Albanian while we
> use it for "Alsatian". This is not acceptable for what we currently do,
> making it compulsory for future new projects is not acceptable either.
> Projects like these should be renamed as they are squatting ligitimate
> codes
> for ligitimate languages.
> Thanks,
> GerardM
>

Asking people to change their URLs is not a good idea. Let's
say the standards changed and EN was no longer English.
Do you honestly think we'd move en.wiki just because some
standards body says we're using the wrong code?

While I agree that it's best practice to follow the standard, forcing
a subdomain change on a project simply to follow a standard is
absurd.

Perhaps moving it to the correct language code and leaving the
old one in place as a redirect could work :)

-Chad
_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Hoi,
The standards did not change. The standard that gave the English language
the code en has been around since 2002. People chose to ignore the standard
and abused codes like als in stead of gsw, they ignored the fact that the
best common practice states that you should not mix the codes with invented
codes. Using codes that are absolutely wrong should not be used for any new
projects. These projects should be renamed.

Renaming and leaving a redirect in place is indeed a great way to move
forward.
Thanks,
GerardM

http://www.sil.org/iso639-3/documentation.asp?id=gsw
http://www.sil.org/iso639-3/documentation.asp?id=als

On Sun, Oct 19, 2008 at 9:26 AM, Chad <innocentkiller@gmail.com> wrote:

> On Sun, Oct 19, 2008 at 1:39 AM, Gerard Meijssen
> <gerard.meijssen@gmail.com>wrote:
>
> > Hoi,
> > Really problematic are codes like the one used for Alsation; the "als"
> > code.
> > This code is according to the standard to be used by Tosk Albanian while
> we
> > use it for "Alsatian". This is not acceptable for what we currently do,
> > making it compulsory for future new projects is not acceptable either.
> > Projects like these should be renamed as they are squatting ligitimate
> > codes
> > for ligitimate languages.
> > Thanks,
> > GerardM
> >
>
> Asking people to change their URLs is not a good idea. Let's
> say the standards changed and EN was no longer English.
> Do you honestly think we'd move en.wiki just because some
> standards body says we're using the wrong code?
>
> While I agree that it's best practice to follow the standard, forcing
> a subdomain change on a project simply to follow a standard is
> absurd.
>
> Perhaps moving it to the correct language code and leaving the
> old one in place as a redirect could work :)
>
> -Chad
> _______________________________________________
> foundation-l mailing list
> foundation-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>
_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

But these are two very different cases. A code like fiu-vro is not
squatting, it is a macrolanguage code plus an invented code. als is
squatting, indeed, but that is a unique situation. I don't see what's
wrong with having xxx-xxx style codes.

Mark

On 18/10/2008, Gerard Meijssen <gerard.meijssen@gmail.com> wrote:
> Hoi,
> Really problematic are codes like the one used for Alsation; the "als" code.
> This code is according to the standard to be used by Tosk Albanian while we
> use it for "Alsatian". This is not acceptable for what we currently do,
> making it compulsory for future new projects is not acceptable either.
> Projects like these should be renamed as they are squatting ligitimate codes
> for ligitimate languages.
> Thanks,
> GerardM
>
> On Sun, Oct 19, 2008 at 12:48 AM, Crazy Lover <
> always_yours.forever@yahoo.com> wrote:
>
>> I add (In language Proposal policy - communiy draft) a clause is for
>> languages with
>> active wikis, but which Code has been invented: voro (fiu-vro), tarantino
>> (roa-tara), Cantonese (zh-yue), min nan (zh-min-nan) , etc.
>>
>> For new proposal those will continue using the same
>> invented code that are using.
>>
>> The problem: Imagine that they will
>> use different codes [.when get a ISO code or if they have: Min nan (nan),
>> Cantonese (yue)] for new projects, the technical chaos that would
>> occur.
>>
>> Please check it out:
>>
>>
>> http://meta.wikimedia.org/wiki/Meta:Language_proposal_policy/Community_draft
>>
>> C.m.l.
>>
>>
>> __________________________________________________
>> Do You Yahoo!?
>> Tired of spam? Yahoo! Mail has the best spam protection around
>> http://mail.yahoo.com
>> _______________________________________________
>> foundation-l mailing list
>> foundation-l@lists.wikimedia.org
>> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>>
> _______________________________________________
> foundation-l mailing list
> foundation-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>

_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Hoi,
First of all, the codes that we all agree on that they are wrong need to be
fixed. Then all the invented codes that are not known to either the RFC 4646
or better the ISO-630-3 need to be registered as such. When the people
supporting these invented codes are not able to argue their case that their
"language" is indeed a linguistic entity, I do not think we should support
them. Mind you, even constructed languages are supported here, so it is just
a matter of demonstrating that it is sufficiently unique.

When we publish our data, we indicate in the meta data what linguistic
entity this is. Given that the codes have to be standardised to be
recognised, invented codes are wrong to have. When the code is something
like fiu-x-vro, the x indicates that it is private designation and can be
safely ignored.
Thanks,
GerardM

On Mon, Oct 20, 2008 at 3:01 AM, Mark Williamson <node.ue@gmail.com> wrote:

> But these are two very different cases. A code like fiu-vro is not
> squatting, it is a macrolanguage code plus an invented code. als is
> squatting, indeed, but that is a unique situation. I don't see what's
> wrong with having xxx-xxx style codes.
>
> Mark
>
> On 18/10/2008, Gerard Meijssen <gerard.meijssen@gmail.com> wrote:
> > Hoi,
> > Really problematic are codes like the one used for Alsation; the "als"
> code.
> > This code is according to the standard to be used by Tosk Albanian while
> we
> > use it for "Alsatian". This is not acceptable for what we currently do,
> > making it compulsory for future new projects is not acceptable either.
> > Projects like these should be renamed as they are squatting ligitimate
> codes
> > for ligitimate languages.
> > Thanks,
> > GerardM
> >
> > On Sun, Oct 19, 2008 at 12:48 AM, Crazy Lover <
> > always_yours.forever@yahoo.com> wrote:
> >
> >> I add (In language Proposal policy - communiy draft) a clause is for
> >> languages with
> >> active wikis, but which Code has been invented: voro (fiu-vro),
> tarantino
> >> (roa-tara), Cantonese (zh-yue), min nan (zh-min-nan) , etc.
> >>
> >> For new proposal those will continue using the same
> >> invented code that are using.
> >>
> >> The problem: Imagine that they will
> >> use different codes [.when get a ISO code or if they have: Min nan (nan),
> >> Cantonese (yue)] for new projects, the technical chaos that would
> >> occur.
> >>
> >> Please check it out:
> >>
> >>
> >>
> http://meta.wikimedia.org/wiki/Meta:Language_proposal_policy/Community_draft
> >>
> >> C.m.l.
> >>
> >>
> >> __________________________________________________
> >> Do You Yahoo!?
> >> Tired of spam? Yahoo! Mail has the best spam protection around
> >> http://mail.yahoo.com
> >> _______________________________________________
> >> foundation-l mailing list
> >> foundation-l@lists.wikimedia.org
> >> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
> >>
> > _______________________________________________
> > foundation-l mailing list
> > foundation-l@lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
> >
>
> _______________________________________________
> foundation-l mailing list
> foundation-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>
_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

In my view Wikimedia should use standards. Where a language lacks a
639 code (and 639-3 is pretty robust) mechanisms exist which are NOT
draconian and overly time-consuming to add either formal codes or
formal subtags which CAN be used and which conform to standards.

If Wikimedia does anything else than follows standards in this area, I
think there ought to be a VERY VERY good reason why.

Michael Everson * http://www.evertype.com


_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l