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
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.
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
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
On Sun, Oct 19, 2008 at 1:39 AM, Gerard Meijssen gerard.meijssen@gmail.comwrote:
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
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.comwrote:
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
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
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
wikimedia-l@lists.wikimedia.org