czalex wrote:

I fully agree with the statements above. Besides that, the renaming would
finally put an end to the divorcement of Belarusian Official and "Classical"
orthography Wikis

regards,

Aleś Čajčyc

ihar.hrachyshka wrote:

Are you all men fully agreed that OUR language is "pre-stalinist"??? Just think
what you say.

Ihar Hrachyshka

bugzilla wrote:

Are you all men fully agreed that OUR language is "pre-stalinist"??? Just think
what you say.

Mienski, I don't have anything against official orthography, and I don't think
it is "stalinist", you know. But, don't split Belarusian language into OUR and
YOUR, ok?

P.S. It's a bugzilla, neither mailing list nor forum/echoconference, so let's
stop off-topic.

• WBR, Andrew

Gerard.meijssen wrote:

There is no consensus about what is to be done. When you look at it from the perspective of the policy of the language committee, this project would not exist in the first place as it is a clear attempt to deny the reality of the prevalent orthography of Belarus.

As long as there is no consensus to merge this unfortunate situation, I think it is best to leave things as they are.
Thanks,

GerardM

jz53x wrote:

Dear Gerard,

I've spent a couple of minutes and googled for some common words, spelling of which differs. Probably, you will be surprised with this.

Please, have a look at the results. The first one is for the official orthography; the second is for the classical orthography (Taraškievica).

(“is”) ёсць: 320,000 results; ёсьць: 320,000 results.
(a form of “world”) свеце: 155,000; сьвеце: 141,000.
(“a century”) стагоддзе: 26,600; стагодзьдзе: 108,000.
(“generation”) пакаленне: 13,400; пакаленьне: 19,400.
(“to sing”) спяваць: 10,800; сьпяваць: 9,790.
(“a wall”) сцяна: 6,050; сьцяна: 13,200.
(“classical”) класічны: 2,810; клясычны: 9,110.
(“philologist”) філолаг: 2,250; філёляг: 3,800.

For sure, this proves nothing to say anything definitely about the variants of the language, and there is no problem to find many contrary results and vice versa. But this helps to see that the term “prevalent orthography” can't be applied today to any of the variants of the Belarusian language. Both of them are used comparatively equally.

Best regards,
Jaska

d.yurtsevich wrote:

Hi all,

Please, make appropriate change as requested as it was well-grounded and is important for our language's Wikipedia.

Regards,
Źmicer.

This seems to have caused something of a mess. We now have be-x-old and be-tarask as separate options virtually everywhere (even though they refer to the same thing). We have these as separate languages in the user prefs, separate languages in CentralNotice, separate languages in Upload Wizard, separate languages in all the various language templates, etc. Is this just because we can't drop be-x-old since its the language code for be-x-old.wikipedia.org? If so, I would support renaming the wiki just we don't have to keep supporting both languages codes in MediaWiki.

Ryan, we've got $wgDummyLanguageCodes for that. Unfortunately, it's not always used, and it needs better support by the Language class itself.

p.selitskas wrote:

(In reply to comment #9)

Ryan, we've got $wgDummyLanguageCodes for that. Unfortunately, it's not always
used, and it needs better support by the Language class itself.

Well, people who write client-side extensions (i.e. JS) don't mind. They write be-x-old and it doesn't work for people with be-tarask locale. I faced this problem many times.

If there could be a way to get rid of 'be-x-old' fallback locale, I wouldn't ask personally to move be-x-old.wiki to be-tarask. And here the discussion has a second go.

Is the $wgDummyLanguageCodes array accessible via Javascript or the API?

Is the $wgDummyLanguageCodes array accessible via Javascript or the API?

It is not, and shouldn't be. Language::getLanguageNames() should be split to two functions, one returning all possible languages (including b/c fallbacks like be-x-old), another returning only "real" languages. All callers should be updated to use either of these.(In reply to comment #11)

That's great for developers in the future, but in the present we're stuck with with a broken system. I guess I'm still not understanding why we want to hang onto be-x-old at all. I understand that some people believe that be-x-old/be-tarask isn't a legit language, but why would that stop us from switching be-x-old to be-tarask? And if we're refusing to switch it based on some principle, why did we introduce be-tarask at all? The situation as it is now is extremely annoying for front-end developers. We have to be aware of all the language deprecations and re-map them by hand in every implementation (and then updated it manually for the rest of time). If this is a policy decision by the language committee, are they aware of the technical problems it causes?

Also, shouldn't de-formal be included in $wgDummyLanguageCodes?

Also, is there a bug filed for implementing the system described in comment #12? I think this is a great idea for fixing the issue long-term.

(In reply to comment #13)

Also, shouldn't de-formal be included in $wgDummyLanguageCodes?

No, it's a separate set of messages, not just a code that does nothing but fall
back to de.

(In reply to comment #14)

Also, is there a bug filed for implementing the system described in comment
#12? I think this is a great idea for fixing the issue long-term.

I came up with this idea right before posting it.

p.selitskas wrote:

After reviewing InitialiseSettings, I can understand why do we have be-x-old no more. The language is set evidently (be-tarask, thanks God!). Moving to be-tarask.wikipedia.org would make the task easier for different tools to map language code to proper wiki and vice-versa.

The most interesting point of this discussion is that there is not even an against opinion.

p.selitskas wrote:

We have MessagesBe_x_old.php no more! See Gerrit change #35383.

Yee-haw! That's Tennessean for "awesome" :)

{{#language:be-x-old}}

now returns now a damned LRM control at end of the name !

I've seen these RLM or LRM marks being inserted magically at random places by the MediaWiki editor when editing or saving pages, even when we never have these controls on our keyboards.

There's certainly an issue in the MediaWiki code editor or VisualEditor about these damned invisible controls.

They cause perfectly valid templates using constructs like
{{#if:{{{1|}}}|then|else}}
to always return the "then" part because some RLM or LRM was magically inserted by the editor in the tested string.

These controls are impossible to see in most cases.

Please fix the wiki code editor (or the VisualEditor or the Lua code editor) so that it will no longer insert them when we don't want them (notably when editing templates, or Lua modules) It seems that some of these editors are automatically inserting them where we never want it. They break things.

The wiki code editor should convert them systematically using named character entities, i.e. ‏ or ‎ if they are allowed in our pages.

In the particular case of language names they are added because of bug 38674.

anything for operations to do here?

In T11823#942828, @fgiunchedi wrote:

anything for operations to do here?

Not really atm... Part of this is working out how to "rename" the database. Or more likely, hack around it. See https://gerrit.wikimedia.org/r/#/c/134962/ (not tested yet). More for external storage than for the usual mysql cluster

Then it's just a DNS entry for be-tarask.wikipedia.org to be added, apache config updated, and rewrites added...

Change 234429 had a related patch set uploaded (by Alex Monk):
Add be-tarask for renaming from be-x-old

https://gerrit.wikimedia.org/r/234429

Change 234429 merged by RobH:
Add be-tarask for renaming from be-x-old

https://gerrit.wikimedia.org/r/234429

Change 235843 had a related patch set uploaded (by Alex Monk):
Map be-tarask.wikipedia.org to be_x_oldwiki

https://gerrit.wikimedia.org/r/235843

I don't believe you need to manually configure each new *.wikipedia.org wiki domain in apache these days. So, once this is done on the MW deployment side, SRE will just be needed to create the redirects in apache config from the old domain to the new one. And then this can be marked as resolved.

Database renaming would be unnecessary and a huge waste of time. (And indeed, waiting for people to figure out how it would be possible to rename databases has already proven itself a huge waste of time.)

Change 235843 merged by jenkins-bot:
Map be-tarask.wikipedia.org to be_x_oldwiki

https://gerrit.wikimedia.org/r/235843

Change 235940 had a related patch set uploaded (by Alex Monk):
Move be-x-old wgServer/wgCanonicalServer to be-tarask

https://gerrit.wikimedia.org/r/235940

Change 235940 merged by jenkins-bot:
Move be-x-old wgServer/wgCanonicalServer to be-tarask

https://gerrit.wikimedia.org/r/235940

Change 235943 had a related patch set uploaded (by Alex Monk):
Redirect be-x-old.wikipedia.org to be-tarask.wikipedia.org

https://gerrit.wikimedia.org/r/235943

Thanks for everyone who has evidently resolved this issue. Can these Wikipedias be merged like the Cyrillic and Latin scripts are for Serbian?

If this is fixed, I think there should be user notice of the change. I assume stuff like MassMessage delivery lists need to be fixed (I had an error in mine today).

In T11823#1613434, @Elitre wrote:

If this is fixed, I think there should be user notice of the change. I assume stuff like MassMessage delivery lists need to be fixed (I had an error in mine today).

We're waiting for ops to approve the redirect before calling this done.

Change 235943 merged by Jcrespo:
Redirect be-x-old.wikipedia.org to be-tarask.wikipedia.org

https://gerrit.wikimedia.org/r/235943

In T11823#1613434, @Elitre wrote:

If this is fixed, I think there should be user notice of the change. I assume stuff like MassMessage delivery lists need to be fixed (I had an error in mine today).

I updated some delivery lists and links.

The users there already noticed it and they are very happy! - https://be-tarask.wikipedia.org/wiki/%D0%92%D1%96%D0%BA%D1%96%D0%BF%D1%8D%D0%B4%D1%8B%D1%8F:%D0%A4%D0%BE%D1%80%D1%83%D0%BC#be-tarask.wikipedia.org

Thank you for doing this!

So, the fallout begins ;)

• T111818
• T111822
• T111850
• T111853

Does anybody object to reopening this task and setting the post-rename cleanup tasks from the previous comment as blockers? It might be useful for doing future renaming more smoothly.

Think it'd be better to create a wikitech page about it.

In T11823#1618341, @Krenair wrote:

Think it'd be better to create a wikitech page about it.

https://wikitech.wikimedia.org/wiki/Rename_a_wiki_domain

Another thing: T111876

In T11823#1613434, @Elitre wrote:

If this is fixed, I think there should be user notice of the change. I assume stuff like MassMessage delivery lists need to be fixed (I had an error in mine today).

Filed T111895: MassMessage input lists need manual updates after a wiki's domain name changes.

Change 237254 had a related patch set uploaded (by Ladsgroup):
be-x-old is renamed to be-tarask

https://gerrit.wikimedia.org/r/237254

Change 237254 merged by jenkins-bot:
be-x-old is renamed to be-tarask

https://gerrit.wikimedia.org/r/237254

Another one that is probably related: T112285.

Change 243055 had a related patch set uploaded (by John Vandenberg):
be-x-old is renamed to be-tarask

https://gerrit.wikimedia.org/r/243055

Change 243055 merged by jenkins-bot:
be-x-old is renamed to be-tarask

https://gerrit.wikimedia.org/r/243055