You don't even need a lot of translations. This is a real problem only for RTL alphabets, where mixing Latin XML-like tags with RTL text is awful. A small number of translations to RTL languages is all that is needed. Translating <ref> to Hindi, Chinese, and Russian can be possible, but I would discourage actually doing it unless there is a good reason to do it.

Case by case, and in this case we do. See the discussions at the langcom mailing list.

Link. No replies yet.

So... I posted it myself eventually because I didn't want to miss the opportunity. I don't write in the Russian Wikipedia that much, but it should work.

Thanks for the summary, @Trizek-WMF.

Done for Hebrew.

In T168292#3362225, @leila wrote:

In T168292#3362138, @Amire80 wrote:

Survey data handled by a third party. Privacy.

Информация об опросе обрабатывается третьей стороной. Конфиденциальность.

Any chance we can make the above shorter? This is going to be shown in the survey widget and space is a problem there. We still want the translation to be identical to the English one where possible. If it's not possible, please don't worry about it.

Now this is something that I'd really prefer somebody more familiar with the Russian Wikipedia communication channels than I am to do, like @Kaganer. Russian is my native language, but I don't actually write in that Wikipedia that much. Thanks for understanding.

OK, so the information in "More details" is the thing to convey, but if I summarize it then it's OK? I'm making sure because for the survey itself translation precision was very important :)

In T168281#3362076, @leila wrote:

@Amire80 can you notify your community about the survey launch on June 22? More details. Please let us know here once you do this with a link to the place the notification has gone to. thanks! :)

Survey data handled by a third party. Privacy.

In T167714#3354889, @DatGuy wrote:

Seems like it's already imported.

In T167714#3350157, @Reedy wrote:

The wiki is now for all intents and purposes, created.

There's a few followup issues (specifically with Wikidata) to be addressed

In T167714#3352669, @Benoit_Rochon wrote:

Right, my bad.

Atikamekw is a very old language and its particular because it's always related to the territory, the earth, the nature, the human being... So I have a question for you. Let say in few weeks, when the users will have the namespaces in the context of Wikipedia, and they realize that one namespace should be corrected because of the context, is it possible to change? Is the impact is only to change "What links here"?

Also, a couple of things I noticed:

• Definitely an error: "Template talk" is the same as "Talk"
• Possibly not an error, but definitely a curious difference: Why is it that in "Module talk" the work for module is in the beginning, while in most other talk namespaces the corresponding word in in the end?
• "User talk" is also quite different from other talk namespaces.

And sorry, I forgot a few:

• Special
• Media

Can this be enabled in Wikimedia projects after T145366 is resolved? Are there any other blockers?

Namespace translations are needed. You can see the list of namespaces here: https://atj.wikipedia.org/w/index.php?title=Special:Search&profile=advanced&search=&fulltext=1 (all the checkboxes)

Fully deployed. Thanks to @Tgr and @Niharika for the help with configuration deployment!

Resolved in the code, but not fully resolved in production. Many wikis still don't actually have Babel fully enabled. This will be resolved later today with https://gerrit.wikimedia.org/r/#/c/358007/ .

The current situation is not made worse by adding these. There is clear and uncontroversial consensus to transition nrm to nrf, and the actual execution is only blocked by technical issues.

Mmm, so the code in Wikibase that reads from Babel can now be updated to use Babel's functions. See https://phabricator.wikimedia.org/diffusion/EBAB/browse/master/Babel.class.php;3c475fe3dacf8dfbdeb22e58a7fb0b77b7bed4a8$352 as a starting point.

In T162172#3280030, @siebrand wrote:

In T162172#3154471, @Nikerabbit wrote:

It's more useful for translators to have related messages appear together.

This is the most relevant reason for things being as they are.

In T167762#3343692, @Nikerabbit wrote:

As a developer, it should be very obvious to which file a new and existing messages belong to. Something like 7 groups would still be very manageable.

I think I know what really bothers me: That the blue circles are considerably larger than the font of the label text.

In T167637#3340793, @ssastry wrote:

@Schnark's argument has merit but I know the hewiki tries to avoid all nowikis.

In T162823#3340526, @hashar wrote:

But fawiki has 9 left over links:

It does work like this:

Done, deployed, and tested!

In T150540#3340003, @MarcoAurelio wrote:

Was there any discussion when they set it to pt? No.

Do you speak galician? I don't think so. I do, not at native level, but I do.

In T150540#3339953, @MarcoAurelio wrote:

No comments on that thread means the patch can go forward?

Domains, sadly, cannot be renamed at least until T112909 is resolved, but to the best of my understanding renaming the domain is not required for resolving this bug.

In T165648#3337873, @Esc3300 wrote:

The purpose of this thread is to allow to define the language of geographic names used in Guernsey in Wikidata statements (with "monolingual text"-datatype properties). Please don't combine or confuse it with open issues already addressed in T25216.

In T165648#3337826, @Esc3300 wrote:

I think T25216 also mentions that current nrmwiki includes languages not covered by nrf.

If I understand correctly, nrf is the standard code, and nrm is a de-facto code that is used in the current domain, and what's worse—in the HTML lang attribute. The domain should be renamed, but current it's technically blocked, but there is a things that can be done: Add it do getDeprecatedCodeMapping in LanguageCode.php, similarly to gsw -> als. This way nrf will be used in the lang attribute, and in most other places. It should also be fixed it in the langdb of jquery.uls.

Are there any blockers for this? Just the script that queries those pages, and then runs the refreshlinks code on them? Can I help with that?

This is deployed. It works in English, Polish, Finnish, and Catalan Wikipedias, but not in Hebrew, possibly because wmgBabelMainCategory is not set, as @Tgr suggested. I'll create a separate issue for that.

Isn't it already in WikibaseRepo.php? Is there anything else to be done?

I have a general question here: Are these languages codes provided in WikibaseRepo.php in addition to anything?

In T162741#3316411, @TJones wrote:

@Amire80:

(1) I haven't dug too deeply into the HebMorph code. But, given the ambiguity of Hebrew, I could see being cautious about automatically removing possible prefixes. English Wiktionary tells me that ויקיפדיה is "Wikipedia" (I picked it at random—really!). If that wasn't in the lexicon, would we want it to also guess that יקיפדיה is a word? It's the classic trade off of recall and precision—do you want to get every possible answer (along with a bunch of extra junk), or get only right answers (but miss a bunch of other right answers)? it's never easy to find the perfect balance.

Thanks a lot for this work.

Yes, but since we don't...

Of course, we need to do support both options: with and without the label with the language names. And possibly other forms as well.

This may be related to the Operations team because it would be a good idea to get their confirmation for this.

I guess that the traffic to wikimediafoundation.org is relatively low, and anonymous selection can be enabled. There's a long discussion about enabling it on Commons, where the traffic is higher and there are concerns about caching issues, but it shouldn't be a problem on wikimediafoundation.org. If ops don't object, it should be done.

... Yep, I now examined the other two examples closely, and it looks like they have the same problem: The user probably wrote the whole article, including footnotes, in an MS-Word document, and copy-pasted all of it.

I don't know exactly what did these users do, but if you look at the diffs linked from the task description and the comments, you'll see that the problematic strings appear in double square brackets.

Yes, but these are pasted as a link, so I'd expect the link inspector to detect it. Such links are never useful as real links on a website. I can imagine them being useful on an internal wiki within an intranet, but not on a site like Wikipedia.

Update:

• This was blocked by files synching on the stat servers, but that is now resolved.
• I'm working on two things:
  • Scheduling daily auto-updates.
  • Converting the existing data to the new files. This is essentially done with a couple of simple Python scripts to run once, and I'll prepend the data to the new data files once they are ready.

I've been seeing it on Firefox for Android for months. Thought that it's a Firefox bug (even though Firefox for Android is actually quite stable). Kinda good to know that it's broken on Chrome, too (I rarely ever use it).

As for the numbers, here are some query results from big wikis:

Can you please report this as a separate bug, and add a screenshot? The
page to which you linked looks correct, but I might be missing something.

Deployed.

The current fonts look OK to me.

Any status is OK as long as the intention is to get rid of the gibberish.