It seems to me that the best immediate solution is for us to assign them a q-code, maybe qmp. This has the following advantages:
* It's something we can do without worrying about anyone else. Q-codes are for local use, so what we do with them is our business. * It's unlikely ever to be overridden by a decision on the part of someone else (SIL or a successor) to assign the code to someone else. * In order for us to maintain compatibility with ISO-compliant systems, we can easily redirect arn.wik*.org > qmp.wik*.org, just as we do now with redirections like yue > zh-yue. * Presumably, if the code arn ever is changed, we could move qmp wikis to the new code in the future. (OK, this has proved hard even now. But if/when it gets solved for already-existing cases, it will be solved for this case as well.)
I suppose it's possible that someone, somewhere, is using qmp for some other local use, and that this will interfere. I think the chance of there being a truly material conflict anywhere is remote. And short of our getting someone to change the code—which may or may not be appropriate, but in any case is not directly within our power—this is probably the best solution in terms of both (a) local ability to implement and (b) unlikeliness of interference in outside systems.
The Mapuche test projects on Incubator have not been very active lately. It shouldn't be too much trouble to move them from W?/arn > W?/qmp.
Steven White (Incubator administrator)
Sent from Outlookhttp://aka.ms/weboutlook
Yes, that seems like an option. We shouldn't perpetuate institutional racism of other important internet organizations.
On Thu, May 18, 2017 at 3:11 PM, Steven White Koala19890@hotmail.com wrote:
It seems to me that the best immediate solution is for us to assign them a q-code, maybe qmp. This has the following advantages:
It's something we can do without worrying about anyone else. Q-codes are for local use, so what we do with them is our business. It's unlikely ever to be overridden by a decision on the part of someone else (SIL or a successor) to assign the code to someone else. In order for us to maintain compatibility with ISO-compliant systems, we can easily redirect arn.wik*.org > qmp.wik*.org, just as we do now with redirections like yue > zh-yue. Presumably, if the code arn ever is changed, we could move qmp wikis to the new code in the future. (OK, this has proved hard even now. But if/when it gets solved for already-existing cases, it will be solved for this case as well.)
I suppose it's possible that someone, somewhere, is using qmp for some other local use, and that this will interfere. I think the chance of there being a truly material conflict anywhere is remote. And short of our getting someone to change the code—which may or may not be appropriate, but in any case is not directly within our power—this is probably the best solution in terms of both (a) local ability to implement and (b) unlikeliness of interference in outside systems.
The Mapuche test projects on Incubator have not been very active lately. It shouldn't be too much trouble to move them from W?/arn > W?/qmp.
Steven White (Incubator administrator)
Sent from Outlook
Langcom mailing list Langcom@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/langcom
Hoi, I am dead set against it. Thanks, GerardM
On 18 May 2017 at 15:26, Milos Rancic millosh@gmail.com wrote:
Yes, that seems like an option. We shouldn't perpetuate institutional racism of other important internet organizations.
On Thu, May 18, 2017 at 3:11 PM, Steven White Koala19890@hotmail.com wrote:
It seems to me that the best immediate solution is for us to assign them
a
q-code, maybe qmp. This has the following advantages:
It's something we can do without worrying about anyone else. Q-codes are
for
local use, so what we do with them is our business. It's unlikely ever to be overridden by a decision on the part of someone else (SIL or a successor) to assign the code to someone else. In order for us to maintain compatibility with ISO-compliant systems, we
can
easily redirect arn.wik*.org > qmp.wik*.org, just as we do now with redirections like yue > zh-yue. Presumably, if the code arn ever is changed, we could move qmp wikis to
the
new code in the future. (OK, this has proved hard even now. But if/when
it
gets solved for already-existing cases, it will be solved for this case
as
well.)
I suppose it's possible that someone, somewhere, is using qmp for some
other
local use, and that this will interfere. I think the chance of there
being a
truly material conflict anywhere is remote. And short of our getting
someone
to change the code—which may or may not be appropriate, but in any case
is
not directly within our power—this is probably the best solution in
terms of
both (a) local ability to implement and (b) unlikeliness of interference
in
outside systems.
The Mapuche test projects on Incubator have not been very active lately.
It
shouldn't be too much trouble to move them from W?/arn > W?/qmp.
Steven White (Incubator administrator)
Sent from Outlook
Langcom mailing list Langcom@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/langcom
Langcom mailing list Langcom@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/langcom
On Thu, May 18, 2017 at 3:33 PM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
I am dead set against it.
When time comes, Language committee will vote about the issue. If it doesn't accept it, we will discuss publicly if Wikimedia movement supports or not institutional racism.
Hoi, We will not discuss it. You bring it up again elsewhere, there is a name for that.. Forum shopping.
Thanks, GerardM
On 18 May 2017 at 15:35, Milos Rancic millosh@gmail.com wrote:
On Thu, May 18, 2017 at 3:33 PM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
I am dead set against it.
When time comes, Language committee will vote about the issue. If it doesn't accept it, we will discuss publicly if Wikimedia movement supports or not institutional racism.
Langcom mailing list Langcom@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/langcom
On Thu, May 18, 2017 at 3:37 PM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
We will not discuss it. You bring it up again elsewhere, there is a name for that.. Forum shopping.
If you wouldn't want to talk on wikimedia-l, it would be your choice.
Maybe we can discuss the idea instead of throwing racism accusations around again.
Do I remember correctly that using a code for private use (q--) was discussed before and rejected for a reason I dont remember?
Am 18.05.2017 3:37 nachm. schrieb "Gerard Meijssen" < gerard.meijssen@gmail.com>:
Hoi, We will not discuss it. You bring it up again elsewhere, there is a name for that.. Forum shopping.
Thanks, GerardM
On 18 May 2017 at 15:35, Milos Rancic millosh@gmail.com wrote:
On Thu, May 18, 2017 at 3:33 PM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
I am dead set against it.
When time comes, Language committee will vote about the issue. If it doesn't accept it, we will discuss publicly if Wikimedia movement supports or not institutional racism.
Langcom mailing list Langcom@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/langcom
Langcom mailing list Langcom@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/langcom
On Thu, May 18, 2017 at 3:39 PM, MF-Warburg mfwarburg@googlemail.com wrote:
Do I remember correctly that using a code for private use (q--) was discussed before and rejected for a reason I dont remember?
Because Gerard was "dead against it".
On 18 May 2017, at 14:11, Steven White Koala19890@hotmail.com wrote:
It seems to me that the best immediate solution is for us to assign them a q-code, maybe qmp.
If we were to do this we would be open to request after request for private-use codes for entities that do not have a valid standard code.
Michael Everson
On Thu, May 18, 2017 at 6:16 PM, Michael Everson everson@evertype.com wrote:
On 18 May 2017, at 14:11, Steven White Koala19890@hotmail.com wrote:
It seems to me that the best immediate solution is for us to assign them a q-code, maybe qmp.
If we were to do this we would be open to request after request for private-use codes for entities that do not have a valid standard code.
Is it possible to solve the problem that way?
On Thu, May 18, 2017 at 6:20 PM, Milos Rancic millosh@gmail.com wrote:
On Thu, May 18, 2017 at 6:16 PM, Michael Everson everson@evertype.com wrote:
On 18 May 2017, at 14:11, Steven White Koala19890@hotmail.com wrote:
It seems to me that the best immediate solution is for us to assign them a q-code, maybe qmp.
If we were to do this we would be open to request after request for private-use codes for entities that do not have a valid standard code.
Forget it. I thought you were talking about a procedure related to JAC.
Yes, we would be open to such requests, but we can reject them, as we are doing that now.
On 18 May 2017, at 17:22, Milos Rancic millosh@gmail.com wrote:
Forget it. I thought you were talking about a procedure related to JAC.
You know the procedure for making a request of the JAC. Go, seek out your colleagues in Chile, and do the work.
Michael Everson
On Thu, May 18, 2017 at 6:27 PM, Michael Everson everson@evertype.com wrote:
On 18 May 2017, at 17:22, Milos Rancic millosh@gmail.com wrote:
Forget it. I thought you were talking about a procedure related to JAC.
You know the procedure for making a request of the JAC. Go, seek out your colleagues in Chile, and do the work.
Thanks for the suggestion.
However, you didn't say anything about your invalid argument.
On 18 May 2017, at 17:20, Milos Rancic millosh@gmail.com wrote:
If we were to do this we would be open to request after request for private-use codes for entities that do not have a valid standard code.
Is it possible to solve the problem that way?
No, because we will oppose the use of private-use codes because we do not wish to be open to request after request for entities that do not have a valid standard code.
Michael Everson
We could make it clear - if we choose this option - that this is an exception for a language which already has a valid standard code.
Am 18.05.2017 6:26 nachm. schrieb "Michael Everson" everson@evertype.com:
On 18 May 2017, at 17:20, Milos Rancic millosh@gmail.com wrote:
If we were to do this we would be open to request after request for
private-use codes for entities that do not have a valid standard code.
Is it possible to solve the problem that way?
No, because we will oppose the use of private-use codes because we do not wish to be open to request after request for entities that do not have a valid standard code.
Michael Everson _______________________________________________ Langcom mailing list Langcom@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/langcom
On 18 May 2017, at 17:31, MF-Warburg mfwarburg@googlemail.com wrote:
We could make it clear - if we choose this option - that this is an exception for a language which already has a valid standard code.
Set floodgates to “open”.
Michael Everson
Guys.
Being a ordinary wikipedian, I would like to let you guys know about my idea. I support the changing of language code this time.
First of all, let's talk about the reason of why we should change the lang code. I think that we should try to think about others. Currently, it is a fact that the "arn" community doesn't like the lang code since they find it offensive. I hope that everyone of you agree on that. At least we have something that we all agree on.
Secondly, about the tech issues. It seems fine using Steven's plan to create redirect links. So I don't see any tech issues making the change impossible.
Finally, let's talk about some concerns you guys raised. About flooded requests using invalid lang codes. I don't think that it would happen. By making it clear to the public that the lang com made the chabge only because the community found the code offensive, I don't think that there will be lots of other requests like this.
I would like to say that. To make this discussion a better one, we should be talking about reasons of why you support or oppose the change. Please stop just saying that "oh I'm dead against it" or "oh it's racism". We need reasons, and possibly examples to support your point.
Yours sincerely,
Gabriel
I am sorry for my bad English. I apologise if my word made you feel offended, I was just trying to bring the discussion on the track.
On Fri, 19 May 2017, 03:40 Michael Everson, everson@evertype.com wrote:
On 18 May 2017, at 17:31, MF-Warburg mfwarburg@googlemail.com wrote:
We could make it clear - if we choose this option - that this is an
exception for a language which already has a valid standard code.
Set floodgates to “open”.
Michael Everson _______________________________________________ Langcom mailing list Langcom@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/langcom