This patch was uploaded by a trusted user on ku.wiktionary. How can we test and deploy the changes?

I have just learned about this markup which allows blocking conversion as well as some flags which i dont understand yet but I'm wondering if I should use this markup to work around current problems or should i wait for Parsoid conversion with T43716

• Syntax of the markup:
• -{code1:text1;code2:text2;...}- or
• -{flags|code1:text1;code2:text2;...}- or
• -{text}- in which case no conversion should take place for text

If anyone is interested here is an open task T359762 requesting some changes to Kurdish language converter.

I have notified the kuwiki community here.

This was previously discussed on meta and ku.wikipedia. In short, it's discussed that ku.wikipedia is the place for all Kurdish languages/dialects which are written in Latin alphabet. And for now the kuwiki community seems to be adamant on keeping the status-quo as is. I'm not a fan of this. I would like to keep the ku.wikipedia for Kurmanji (Northern Kurdish written in Latin Alphabet) without changing the language code. Because CLDR recommends using "ku" code for Kurmanji (Northern Kurdish written in Latin Alphabet as in Turkey) See here for CLDR.

@Jdrewniak Do you have any idea why it says "75.000+" for ku instead of "75.000+ articles" on wikipedia.org? I couldn't find where to correct this problem.

In T282486#9422018, @Lydia_Pintscher wrote:

From the Wikidata PM side this unfortunately is still not ok to do.

As someone who works on kuwikipedia and kuwiktionary for the sole purpose of protecting a dying language, Why was I forced to learn Petscan and Quickstatements, make thousands of edits to Wikidata when this could have easily been achieved by allowing local short descriptions to wikis in the first place, if you were going to make short descriptions appear on all pages on mobile as well as search box on web? In my humble opinion someone should make an RFC on meta wiki to allow local descriptions on all wikis if they choose to do so.

The underlying problem is Short descriptions are set on Wikidata and imported to local projects. It should be the other way around. Local wikis should set the short descriptions for their articles locally and Wikidata should automatically use those descriptions for a given language code, if they wish.

@Aklapper
This is the main reason "Kurdish Wikipedia editors need to be able to see, edit and effectively moderate the short descriptions on desktop and mobile web, without becoming active Wikidata editors." T282504 (Reconsider the design of ShortDescription extension) does not resolve this problem. Because There are thousands of pages where setting the local description can be done through a template. Infoboxes can easily set the local description for example. Most of our users have low to none tech knowledge and mostly they are on mobile. Teaching them to use a template that uses {{SHORTDESC}} would be much easier than teaching them how to edit a Wikidata description. We also have a lot of pages not connected to Wikidata and we would like to set their descriptions locally instead of trying to create their items and cause multiple instances of same entity.

In T353711#9416970, @Reedy wrote:

It is unclear what you're actually requesting. There is no Extension:ShortDescriptions (plural).

Do you actually mean https://www.mediawiki.org/wiki/Extension:ShortDescription ? If so, this is basically blocked on the extension going through https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment

See also: T282504: Reconsider the Wikidata short description workflow and T282170: Move "Short Descriptions" feature outside of main Wikibase.git code.

If you're actually following the request of T282486: Enable local short descriptions on fawiki, this isn't a seperate extension (nor is it the one I mention above), but a feature flag inside MediaWiki-extensions-Wikibase-Client, which results in $wgWBClientSettings['allowLocalShortDesc'] = true; being set. Which in theory is a much lower barrier to entry, but previous requests have been denied; {T204136#4584681} and T279829: Enable magic word SHORTDESC on German-language Wikipedia.

Pleasure. Sorry for the initial confusion!

What I mean by machine translation is the built-in machine translation on the Content Translation tool. People have been abusing this tool by publishing low quality translations which are basically unmodified machine translations. We have the same problem on ku.wiki. After reading the Translation quality help page, I discussed the issue with @UOzurumba who suggested making the Machine translation stricter by maybe 10%. When I discussed the issue with local contibutors, we came to an agreement that we should start with a higher restriction and lower the restrictions per user feedbacks.

ckb.wikipedia has the same problem. In their case, tho, the numbers are in Arabic script but the month names are in English.

Hi @Aklapper The voting is finally done. We can continue now. Thank you!

Hi @RhinosF1 I'm new to the Phabricator and i wasn't aware all the requests have to be voted on first. I discussed the need for this Namespace with one of the longterm users of Wîkîferheng here 1 and he warned me to create a voting, first. As soon as the voting is finalized (September 25), I will update this page. If you wish so, we can cancel the task and create another one once the voting is done, as well.