In T225398#5270644, @Petar.petkovic wrote:

Since only enwiki currently really uses this config, we could make that user needs to be part of any group listed and then add "sysop" to the list.

Yes, I am a sysop.

A bit more details:

I've just managed to reproduce it.

OK, thanks for the clarification. If the functionality is the same, then it may be fine to use the same messages on desktop and on mobile. However, it is also imaginable that there will be issues with this. For example, that in mobile context the messages won't fit well in some languages. So be ready to add new message keys if translators or users ask for it, even if the English strings will be the same.

In T225568#5259568, @ppelberg wrote:

For this iteration, this is correct. No additional new messages need to be added or translated because for v1.0 we decided not to make any changes to the text strings within the Edit Cards UI. (Read: we are recycling language from the desktop link inspector. See screenshot below.)

I'll be fine with whatever allows me to build a chart that shows the three things:

1. Published articles (from wikishared)
2. Articles that need review (from EventLogging)
3. Articles that were deleted (from wiki databases)

Relevant update at T210138#5256469.

I'm trying to resolve it together with T209868#5232506.

In T225362#5245679, @Aklapper wrote:

In T225362#5245611, @Amire80 wrote:

Perhaps you can simply import the version from the English Wikipedia: https://en.wikipedia.org/wiki/MediaWiki:Gadget-SidebarTranslate.js

Also see https://www.mediawiki.org/wiki/ResourceLoader/Migration_guide_(users)#Keep_gadgets_central why to not copy and paste code and then not maintain the copied code and let the copied code rot...

Perhaps you can simply import the version from the English Wikipedia: https://en.wikipedia.org/wiki/MediaWiki:Gadget-SidebarTranslate.js

I cannot reproduce it as an anonymous user or as Amire80.

Now that I'm actually thinking about it a bit more, here are some thoughts about what this may entail other than just a deployment:

As a pet project, I've been trying to build a smarter way to write such strings in jquery.ime and core MediaWiki, so that they would be universally translatable, with completely correct grammar. I'm still far from achieving it, unfortunately.

OK, so now thanks to @mforns the chart works at https://language-reportcard.wmflabs.org/cx2/#cx-2-translations-that-need-review . However, this task ask to put the chart at the "CX2 translations that need review" tab together with the "CX2 translations" tab, as just one tab with two lines. I guess that this may be possible by editing the JSON configuration at https://meta.wikimedia.org/wiki/Config:Dashiki:CX2Translations , but I'm not sure how exactly.

As far as I can see, the charts look sensible now, continuously since 2016 until 2019-05-12. This is already very good. I was a bit concerned that some data after November 2018 was lost, but appears good. Thanks!

Is this issue unique to Slovak? Isn't it very similar in French, German, Italian, Spanish, and Czech? I imagine that whatever works for these languages, should work for Slovak, too.

Good initiative. I occasionally remove unused messages it when I happen to find them, but I don't hunt them systematically.

If I run this query in hive on stat2007, I see sensible data:

select '2018-05-20' AS date,
       weekly_navigation_count.project,
       navigation_count_total / view_count_total as percent_interlanguage_navigation

I'll clarify. It suddenly drops for all languages in November 2018. This isn't supposed to happen: all languages must be shown continuously, to the current week. However, if you select "null" in the list of projects in the sidebar, you'll see that it starts working in November 2018. So something happened then that made all languages collapse into "null". "null" is invalid, and it isn't supposed to be there at all. The list at the sidebar is supposed to include only Wikipedia, Wikisource, and Wikivoyage projects in all the valid languages. The Wikipedia projects are supposed to have non-zero data from mid-2016 until today (for Wikisource and Wikivoyage, the data collection began in December 2017).

Tagging as Analytics-Dashiki, but please move it to the right product if needed.

I noticed https://github.com/MusikAnimal/pageviews/commit/34d62de36701246dbb1604ae23b2cbd30999b056 because of the many changes in the i18n files, and I have a little comment about it, and this is probably the best place for it.

OK, just to be sure:

Makes sense to me.

Where are you testing this?

ULS is perfectly appropriate, but as Nikerabbit says, what needs to be done is to take almost all languages in langdb, filter out a few unneeded ones, and pass that as the languages parameter in ULS initialization. Perhaps this deserves a new langdb function, I'll take a closer look.

In T222309#5203987, @Nikerabbit wrote:

FYI: wgULSLanguages is a JavaScript variable generated by the ULS extension. It lists the languages that are available as interface languages in MediaWiki. sms doesn't have enough translations to be available as an interface language. The question is how and where includeLanguage (singular?) is defined. Alternatively, a new variable could be introduced that lists the languages allowed for captions.

I've looked a bit too deeply into the WikibaseMediaInfo code, and maybe I see the area where the problem happens, but it should be checked by @Cparle and @egardner who appear to have written the relevant parts. It's also possible that I'm totally off the mark.

In T222309#5203361, @SandraF_WMF wrote:

According to @Ramsey-WMF this is not something that can be fixed by the StructuredDataOnCommons team as the issue lies elsewhere. Pinging a few other people: @Ladsgroup @Amire80 @Nikerabbit who may have a lead on this.

Thank you. An email from linguists who are familiar with these languages will be perfect.

I didn't remove any, but I had questions about the autonyms. See my comments at https://github.com/wikimedia/language-data/pull/53

The chart works as is, but as a follow-up, I made T223958.

How about this system:

1. Thanks!
2. These are richer in special characters than some languages of Africa! Cool as it is for typography geeks like me, I occasionally wonder what were the people who came with orthographies like these thinking to themselves: Were they sincerely trying to make them phonetically precise, or were they trying to make them damn hard to write so that people would just stick to the "bigger" language? ;)

In T201527#5197335, @jhsoby-WMNO wrote:

@Yupik Yes! In fact, I had already uploaded a patch for this on GitHub (see here), but it is not working as intended. I was/am doing this in other "downtime", so I haven't been prioritizing it much.

The main problem for me is that it is not possible (as far as I know) to use the normal modifier keys, e.g. AltGr, to get the special characters.

In T223524#5195020, @Yupik wrote:

In T223524#5194770, @Amire80 wrote:

The autonym for rmy could also use a better reference, as I noted in https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/511054/ .

The whole autonym requirement doesn't work for dead languages or for languages we only have an oral source for though. So we unfortunately end up with unusable data from languages that we will never be able to find an autonym for in the case of dead languages or a reliable source for both cases.

The autonym for rmy could also use a better reference, as I noted in https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/511054/ .

In T55590#5192906, @Esanders wrote:

In T55590#5192101, @Amire80 wrote:

There is no good reason for this differentiation. Many templates could be first-class features like "Cite", although global templates should probably implemented first.

I think the distinction at the moment is that the Cite tools relate to extension functionality defined in the code, specifically templates wrapped in a <ref>, and the Citoid tool allows automatic population of those templates.

This development looks good as a step forward. It's certainly better to have a cross-wiki uniform way for listing community curated things, than having local hacks on wikis.

This is deployed. Thanks to @Raymond. You can now translate MediaWiki into this language.

Fantastic, thank you.

Thanks for the request.

I mean, resolved.

Yes, can be merged.

Sorry I missed this earlier!

I eventually decided to do this in mysql, and perhaps later move everything to hive if it's desirable. This is supposed to make the initial deployment easier.

So I have the events being logged, and to show them on the chart, I'll have to do something like this regularly:

In T222505#5161962, @cooltey wrote:

Hi @YaronSh and @Amire80

The Android XML does not support the wikitext format, which texts contain the double parentheses, such as {{PLURAL|one=Last year|%d years ago}}.

Did it work recently?

I'm not sure when did this happen. I'm having a hard time even finding it in the Git history. This definitely doesn't look right, however.

This is already done at https://github.com/wikimedia/language-data/commit/0fa70d9beeb26cf883aeb099391a8cf32a1edb49 . For technical reasons it may take a bit of time to get it deployed to Wikimedia sites, but I hope it will happen as soon as possible. Thanks for the patience :)

In T221994#5141736, @Zoranzoki21 wrote:

Assigned to @Amire80 as he made patch already: https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/497107/

The long story about Hebrew; you can skip it unless you are a typography geek:

Global templates (T121470) definitely are the right solution. Global templates are don't just about translatable—they are also about easing the burden of maintaining code that should be common, and about making the templates semantic. ("Semantic" means, for example, that it will be possible to define the function of the template in a way that will be machine-readable and cross-project, and that it will be possible to add a button to the VE toolbar that inserts the template in a meaningful and easy way, without having to write complex ultra-custom gadgets.)

I think it should be done now. Can you check please?

Any improvement that automates the procedure at https://wikitech.wikimedia.org/wiki/Add_a_wiki is a good step in the direction of implementing this. As the beginning of this task's description says, this task is a version of T158730 that addresses the user-facing aspects of creating new empty wikis, mostly in underresourced "small" languages (they are small only in their presence on the web, but some of them have millions of speakers).

I'm really not much of a Java or Android coder, but as far as I can see, the relevant code is this:

This is definitely not a Content Translation issue, and probably not a translatewiki issue either.

In problem #1 both screenshots look broken in different ways :)

OK, now I've looked at the code properly and I see formatDuration. It's kind of like a simplified Moment.js, for PHP. Like Moment.js, it's good for standalone expressions, but not necessarily for embedding in sentences.

The initial task description applies also to Russian and probably most other Slavic languages.

It will be a very nice bonus if you can write a little user manual for it at this URL:

It's good. Thanks a lot for your work, @zypA13510.

This happens because the Unicode bidi algorithm tries to re-arrange numbers and letters from different alphabets and cannot guess the user's intention correctly. This is especially common on MediaWiki sites with page titles, usernames, and IP addresses.