Page MenuHomePhabricator

Display human-readable wiki names for cross-wiki notifications
Closed, ResolvedPublic

Description

The current (WIP) code only shows DB names, so in production that would display something like "enwiki" or "ptwikibooks" or "commonswiki". What we'd like to show is human-readable names like "Wikipedia - English", "Wiktionary - Portuguese" or "Commons". @Pginer-WMF also suggested that if you're on a Wikpedia (and all wikis listed are Wikipedias?) we should simply display "English" rather than "Wikipedia - English".


See also:

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Change 266474 had a related patch set uploaded (by Matthias Mullie):
Display human-readable wiki names for cross-wiki notifications

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

I like the idea of translateable messages for each wiki, and I agree that it should be possible to automate the translation in many cases. You might be able to do a lot with some {{subst:#language:xx|{{subst:SUBPAGENAME}}}} magic (depending on whether that works in your language). One trick is going to be handling the wikis where the dbname and language code differ (do we have a list of them somewhere already? I'd imagine Wikidata needs it).

The {{subst}} idea is interesting. For the moment, I'm "simply" working on automating the creation of the base English i18n messages using 'sitematrix' API. It seems to go fairly well (though the code looks quite crappy, but is also only meant to be run once, so...)

I'm hoping that afterwards we might be able to use the same code for other languages so we get a solid basis for translators to go and patch up.

First step is English, though. English, and qqq.

I'll probably be doing this for Polish and I'll try documenting how I did it. {{#language}} won't work here, since we need the language name in locative case (https://en.wikipedia.org/wiki/Polish_grammar#Nouns). But we needed that in the past and somebody has compiled a wonderful map of language codes to various grammatical forms (https://pl.wikipedia.org/wiki/Moduł:Lang/data) and I'll be using that instead.

On a side note, after this happens, a new step will have to be added to https://wikitech.wikimedia.org/wiki/Add_a_wiki. Please don't forget about the documentation :)

Yes! You're the fourth person to mention this today. Good point, and yes, it should be added there once we settle on the right key and conventions.

Another thought: I'm afraid this might end up never being translated for many smaller languages. (Or just ones that don't have anyone active who knows how to automate this work, and don't have anyone with the motivation to translate a couple hundred language names by hand.) Can we do something smart for them? It might be better to fall back not to English, as is usual, but to something that uses the localised language name (which we have available via CLDR) and the localised project name (which we could surely extract from our sites' config).

We thought about having a fallback that is basically the Project - Language string. So far, it's just an annoying endeavor, because quite a lot of the wiki's dbnames are not quite following a the proper structure for "siteFromDB" to recognize -- but it might still be a decent fallback regardless.

Can/should we place the automatically generated names somewhere which we can link from qqq?

Change 265876 abandoned by Mooeypoo:
[EXPERIMENTAL] [WIP] Hack a human-readable temporary solution for wiki names

Reason:
This is implemented better in Ic14fe65f4ecc
(Though still requires some work for exception in names)

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

Update, here is a preliminary list of generated project names: https://gist.github.com/mooeypoo/011120a9748a4e06bcf2

The list is mostly great, with some exceptions that come from having no English translation in CLDR and/or no proper way to get site name in the case of the "special" wikis (Wikimedia chapter wikis, etc)

I am tweaking the generator a bit, but overall, I think the list is fairly good. We can tweak the remaining faulty names by hand, since there aren't that many of them.

Can/should we place the automatically generated names somewhere which we can link from qqq?

We can put them in a mediawiki page somewhere, I imagine, if that works? The plan right now is to add those i18n messages to WikimediaMessages anyways.

Also, yes. We need the messages for qqq.json, as well. What should the qqq message format be? Should we include the dbname for the wikis or the generated names?

Something like this:

"project-humanreadable-name-commonswiki": "The localized project name of Wikimedia Commons";
"project-humanreadable-name-zh_min_nanwiki": "The localized project name of Chinese (Min Nan) Wikipedia";
"project-humanreadable-name-angwikisource": "The localized project name of Old English Wikisource";

Or this:

"project-humanreadable-name-commonswiki": "The localized project name of commonswiki";
"project-humanreadable-name-zh_min_nanwiki": "The localized project name of zh_min_nanwiki";
"project-humanreadable-name-angwikisource": "The localized project name of angwikisource";

On one hand, the first is cleaerer. On the other, translators will already see the English translation as a base, and the dbname is the consistent "identifier" of these wikis.

Thoughts?

Maybe the url if that is easy to get? Or dbname if that is not possible. Then something like {{projectname|url}} on qqq for each message and create that template on translatewiki.net.

Mooeypoo added a comment.EditedJan 27 2016, 7:54 PM

Maybe the url if that is easy to get? Or dbname if that is not possible. Then something like {{projectname|url}} on qqq for each message and create that template on translatewiki.net.

Yep, the URL exists. I can also do [URL ProjectName] as a link without having to go through templates.

My point for template was rather to include the whole burb "this is a project name for bar... see foo for automatically generated names" to make it easier to make changes to the text.

Leaving a comment here at the request of @mattflaschen. The Android app does not have notifications yet. We do have a similar requirement, I think, to generate the languages names[0] and special page titles[1] for each language. These definitions are currently baked statically into the app.

[0] https://phabricator.wikimedia.org/diffusion/APAW/browse/master/scripts/generate_wiki_languages.py
[1] https://phabricator.wikimedia.org/diffusion/APAW/browse/master/scripts/make-templates.py

Leaving a comment here at the request of @mattflaschen. The Android app does not have notifications yet. We do have a similar requirement, I think, to generate the languages names[0] and special page titles[1] for each language. These definitions are currently baked statically into the app.

[0] https://phabricator.wikimedia.org/diffusion/APAW/browse/master/scripts/generate_wiki_languages.py
[1] https://phabricator.wikimedia.org/diffusion/APAW/browse/master/scripts/make-templates.py

That's great that you are also interested in this solution, it validates the intent of making sure other projects can also have a good solution.

I've generated a preliminary output here that includes the i18n messages. It's not completely done yet (I need to manually edit a few of the results) but it gives a good idea of how things look.

Can you take a look at it and make sure it covers your need ? If not, now's the time to adjust ...
https://gist.github.com/mooeypoo/011120a9748a4e06bcf2

@Mooeypoo, if I understand correctly this Gist would replace only our Wikipedia main page title generation code[0]. We're currently visiting each wiki's main page directly and getting the title from main_page_name. Will this be the canonical way of getting the main page titles from now on?

I like the note on qqq strings mentioned earlier in the thread. The consideration for Chinese dialects is nice as well[1].

I'm sure we can make any output work but it might be slightly more readable if the key had the wiki language code and project code separated by a hyphen.

[0] https://phabricator.wikimedia.org/diffusion/APAW/browse/master/scripts/make-templates.py;0532e036dfe94290a8857a058df12159649f38b3$133
[1] Hardcoded in our scripts https://phabricator.wikimedia.org/diffusion/APAW/browse/master/scripts/make-templates.py;0532e036dfe94290a8857a058df12159649f38b3$98

@Mooeypoo, if I understand correctly this Gist would replace only our Wikipedia main page title generation code[0]. We're currently visiting each wiki's main page directly and getting the title from main_page_name. Will this be the canonical way of getting the main page titles from now on?

This is the hope. We need this in Echo as the title for wikis in the Cross-Wiki notification feature (in case you have notifications from another wiki) that can appear in the user's interface language. The hope was that this is also useful for other projects, since there is no real proper and consistent way to get those actual project names in a localized language.

I like the note on qqq strings mentioned earlier in the thread. The consideration for Chinese dialects is nice as well[1].

I'm sure we can make any output work but it might be slightly more readable if the key had the wiki language code and project code separated by a hyphen.

The way I created the keys is by the dbname, which is the only real consistent way to get the identifier of a project. The problem of using a language key is that many of our projects:

  1. Don't have a language associated with them, or a language that has a proper key (all of the "special" wikis, like wikidata, commons, meta, etc)
  2. Have a language associated with them that doesn't have the correct key (https://be-tarask.wikipedia.org, https://gsw.wikipedia.org, be-x-old.wikipedia.org, and others)

So we have separated the principle of attaching an actual language to a wiki project and using its name. That's why the i18n keys use dbname and not language key.

Leaving a comment here at the request of @mattflaschen. The Android app does not have notifications yet. We do have a similar requirement, I think, to generate the languages names[0] and special page titles[1] for each language. These definitions are currently baked statically into the app.

Thanks for clarifying, @Niedzielski. I ran generate_wiki_languages.py, and it looks like it generates the language names in both the language itself and English. This seems to be for languages where there is a Wikipedia.

It looks like make-templates.py is for Wikipedias as well.

For our use case, we also need an unambiguous way to refer to non-Wikipedia projects. So we need to be able to say "Spanish Wikipedia", but also "German Wiktionary", "Chinese Wikivoyage", "Wikimedia Commons", etc., all ideally in every supported language (understanding some of these translations won't be available at first, but the i18n keys will be there) (We may use a different fallback if the translation isn't available, rather than the normal fallback chain).

@Mooeypoo, if I understand correctly this Gist would replace only our Wikipedia main page title generation code[0]. We're currently visiting each wiki's main page directly and getting the title from main_page_name. Will this be the canonical way of getting the main page titles from now on?

No, the task does not implement that. The way you're doing that seems correct to me.

@Mooeypoo, if I understand correctly this Gist would replace only our Wikipedia main page title generation code[0]. We're currently visiting each wiki's main page directly and getting the title from main_page_name.

Sorry, I read too quickly before. It's actually not visiting the main page (anymore?). It's hitting API:Allmessages and requesting 'Mainpage', which as mentioned I think is correct (as long as the default language this uses is the content language).

In T121936#1971619, @Mattflaschen wrote:

For our use case, we also need an unambiguous way to refer to non-Wikipedia projects. So we need to be able to say "Spanish Wikipedia", but also "German Wiktionary", "Chinese Wikivoyage", "Wikimedia Commons", etc., all ideally in every supported language (understanding some of these translations won't be available at first, but the i18n keys will be there) (We may use a different fallback if the translation isn't available, rather than the normal fallback chain).

Also, we need "Spanish Wikipedia" in all languages, not just in Spanish and in English. That's extremely hard (if not impossible) to properly get from the main page or a completely automated process.

@Mooeypoo, if I understand correctly this Gist would replace only our Wikipedia main page title generation code[0]. We're currently visiting each wiki's main page directly and getting the title from main_page_name. Will this be the canonical way of getting the main page titles from now on?

No, the task does not implement that. The way you're doing that seems correct to me.

In T121936#1971633, @Mattflaschen wrote:

@Mooeypoo, if I understand correctly this Gist would replace only our Wikipedia main page title generation code[0]. We're currently visiting each wiki's main page directly and getting the title from main_page_name.

Sorry, I read too quickly before. It's actually not visiting the main page (anymore?). It's hitting API:Allmessages and requesting 'Mainpage', which as mentioned I think is correct (as long as the default language this uses is the content language).

If I understand correctly, this retrieves the name of the page "Main page" in whatever interface language the use is in? That is not the use case we are are looking to fix; we are looking for the "proper name" of the project in all languages, not just the translation of the main page.

If I understand correctly, this retrieves the name of the page "Main page" in whatever interface language the use is in?

Since the main page is actually a page, there is only one name, in the content language. If you go to https://en.wikipedia.org/?uselang=es the UI is in Spanish, but the actual page you're on is still Main Page (but the title varies by project).

In T121936#1971667, @Mattflaschen wrote:

If I understand correctly, this retrieves the name of the page "Main page" in whatever interface language the use is in?

Since the main page is actually a page, there is only one name, in the content language. If you go to https://en.wikipedia.org/?uselang=es the UI is in Spanish, but the actual page you're on is still Main Page (but the title varies by project).

Okay, yes, thanks, that's what I thought. That's not our use case.

That's why the i18n keys use dbname and not language key.

@Mooeypoo, nice! For the Android client, is it correct then that dbname is lang + "wiki" + suffix? We get a list of languages[0] and try to map the Android system language code to one of them. We would have to special case anything that doesn't match the above formula.

we also need an unambiguous way to refer to non-Wikipedia projects.

@Mattflaschen, if that's the case, I don't think we currently have a need for this functionality unless we should be calling Wikipedia, "English Wikipedia", and so forth. There have been discussions to implement notifications in app though, so this might be nice if we add that feature.

I should have clarified earlier. generate_wiki_languages.py builds a list of languages. Each entry has the language code, the English name, and the localized name. make-templates.py builds gets the localized title of special, file, and main pages in each language.

Thank you for your patience.

[0] https://wikistats.wmflabs.org/api.php?action=dump&table=wikipedias&format=csv&s=good

That's why the i18n keys use dbname and not language key.

@Mooeypoo, nice! For the Android client, is it correct then that dbname is lang + "wiki" + suffix? We get a list of languages[0] and try to map the Android system language code to one of them. We would have to special case anything that doesn't match the above formula.

For the most part, it seems so, but there are exceptions (as I have experienced in the past few days... meh)

we also need an unambiguous way to refer to non-Wikipedia projects.

@Mattflaschen, if that's the case, I don't think we currently have a need for this functionality unless we should be calling Wikipedia, "English Wikipedia", and so forth. There have been discussions to implement notifications in app though, so this might be nice if we add that feature.

I should have clarified earlier. generate_wiki_languages.py builds a list of languages. Each entry has the language code, the English name, and the localized name. make-templates.py builds gets the localized title of special, file, and main pages in each language.

Thank you for your patience.

[0] https://wikistats.wmflabs.org/api.php?action=dump&table=wikipedias&format=csv&s=good

Right, there's a difference in our cases between needing a language list and a name/title list.

Thanks for clarifying and verifying!

That's why the i18n keys use dbname and not language key.

@Mooeypoo, nice! For the Android client, is it correct then that dbname is lang + "wiki" + suffix? We get a list of languages[0] and try to map the Android system language code to one of them. We would have to special case anything that doesn't match the above formula.

In a perfect world, yes, but in practice, no. We have several wikis where the dbname or the URL is different from the content language code, mostly for historical reasons. For example: the language of alswiki (https://als.wikipedia.org/) is "gsw"; the language of be_x_oldwiki (https://be-tarask.wikipedia.org/) is "be-tarask"; the language of simplewiki (https://simple.wikipedia.org/) is "en".

Change 266954 had a related patch set uploaded (by Mooeypoo):
[wip] Add a list of human-readable localized project names

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

I've changed the keys to "project-localized-name-{dbname}' for clarity.

The commit is WIP as I am working on the manual corrections for the projects that didn't go through the auto-generation properly.

These are the keys that failed auto-generation:

"project-localized-name-azbwiki": "\u062a\u06c6\u0631\u06a9\u062c\u0647 Wikipedia",
"project-localized-name-be_x_oldwiki": "\u0431\u0435\u043b\u0430\u0440\u0443\u0441\u043a\u0430\u044f (\u0442\u0430\u0440\u0430\u0448\u043a\u0435\u0432\u0456\u0446\u0430)\u200e Wikipedia",
"project-localized-name-bhwiki": "\u092d\u094b\u091c\u092a\u0941\u0930\u0940 Wikipedia",
"project-localized-name-bhwiktionary": "\u092d\u094b\u091c\u092a\u0941\u0930\u0940 Wiktionary",
"project-localized-name-bxrwiki": "\u0431\u0443\u0440\u044f\u0430\u0434 Wikipedia",
"project-localized-name-lbewiki": "\u043b\u0430\u043a\u043a\u0443 Wikipedia",
"project-localized-name-mowiki": "\u043c\u043e\u043b\u0434\u043e\u0432\u0435\u043d\u044f\u0441\u043a\u044d Wikipedia",
"project-localized-name-mowiktionary": "\u043c\u043e\u043b\u0434\u043e\u0432\u0435\u043d\u044f\u0441\u043a\u044d Wiktionary",
"project-localized-name-bdwikimedia": "\u0989\u0987\u0995\u09bf\u09ae\u09bf\u09a1\u09bf\u09af\u09bc\u09be \u09ac\u09be\u0982\u09b2\u09be\u09a6\u09c7\u09b6",
"project-localized-name-cnwikimedia": "\u4e2d\u56fd\u7ef4\u57fa\u5a92\u4f53\u7528\u6237\u7ec4",
"project-localized-name-ilwikimedia": "\u05d5\u05d9\u05e7\u05d9\u05de\u05d3\u05d9\u05d4",
"project-localized-name-mkwikimedia": "\u0412\u0438\u043a\u0438\u043c\u0435\u0434\u0438\u0458\u0430 \u041c\u0430\u043a\u0435\u0434\u043e\u043d\u0438\u0458\u0430",
"project-localized-name-mxwikimedia": "Wikimedia M\u00e9xico",
"project-localized-name-rswikimedia": "\u0412\u0438\u043a\u0438\u043c\u0435\u0434\u0438\u0458\u0430",
"project-localized-name-ruwikimedia": "\u0412\u0438\u043a\u0438\u043c\u0435\u0434\u0438\u0430",
"project-localized-name-trwikimedia": "Wikimedia T\u00fcrkiye",
"project-localized-name-uawikimedia": "\u0412\u0456\u043a\u0456\u043c\u0435\u0434\u0456\u0430 \u0423\u043a\u0440\u0430\u0457\u043d\u0430",

I have manually added those keys to the script to change both the en.json and qqq.json at once.

Manual fixes for wikis:

"azbwiki" => "South Azerbaijani Wikipedia",
"be_x_oldwiki" => "Taraškievica Wikipedia",
"bhwiki" => "Bihari Wikipedia",
"bhwiktionary" => "Bihari Wiktionary",
"bxrwiki" => "Buryat Wikipedia",
"lbewiki" => "Laki Wikipedia",
"mowiki" => "Moldovan Wikipedia",
"mowiktionary" => "Moldovan Wiktionary",

Manual fixes for "special" wikis:

"bdwikimedia" => "Wikimedia Bangladesh",
"cnwikimedia" => "Wikimedia China",
"ilwikimedia" => "Wikimedia Israel",
"mkwikimedia" => "Wikimedia Macedonia",
"mxwikimedia" => "Wikimedia Mexico",
"rswikimedia" => "Wikimedia Serbia",
"ruwikimedia" => "Wikimedia Russia",
"trwikimedia" => "Wikimedia Turkey",
"uawikimedia" => "Wikimedia Ukraine",

After the adjustments above, the script generated what seems to be a working list. Please go over it and review!

https://gerrit.wikimedia.org/r/#/c/266954/

Nemo_bis removed a subscriber: Nemo_bis.Jan 29 2016, 2:22 PM

Can/should we place the automatically generated names somewhere which we can link from qqq?

I don't think this is necessary, and I'm concerned people may think this static list needs to be up to date, when really only the translations and en.json matter. If there's no static list, people won't spend time on updating it.

In T121936#1988798, @Mattflaschen wrote:

Can/should we place the automatically generated names somewhere which we can link from qqq?

I don't think this is necessary, and I'm concerned people may think this static list needs to be up to date, when really only the translations and en.json matter. If there's no static list, people won't spend time on updating it.

Pages can be protected.

There should be some place to at least check the names of the languages. Maybe we could use {{#languagename}} to qqq to produce them, but we should avoid the language code mismatches we have.

I'll keep this moving while Moriel is at linux.conf.au.

In T121936#1988798, @Mattflaschen wrote:

Can/should we place the automatically generated names somewhere which we can link from qqq?

I don't think this is necessary, and I'm concerned people may think this static list needs to be up to date, when really only the translations and en.json matter. If there's no static list, people won't spend time on updating it.

Pages can be protected.

There should be some place to at least check the names of the languages. Maybe we could use {{#languagename}} to qqq to produce them, but we should avoid the language code mismatches we have.

I think people could check against en.json (if the auto-generated en.json is wrong, the auto-generated table would also be wrong).

Nevertheless, let me know if P2561 solves the issue you're thinking of.

I updated https://gerrit.wikimedia.org/r/#/c/266461/ to generate wikitext for this table (as well as display it immediately for convenience).

Like en.json and qqq.json, the table would be auto-generated one time. After that, individual wikis would be added manually to en.json, qqq.json, and (if we use it) the table.

I'll try to clarify: I would like to provide translators the localised language name from CLDR if available. This helps to make consistent translations even though they cannot be used as-is in most languages. We can do that with #languagename in message documentation if we know the language code (if relevant).

I'll try to clarify: I would like to provide translators the localised language name from CLDR if available. This helps to make consistent translations even though they cannot be used as-is in most languages. We can do that with #languagename in message documentation if we know the language code (if relevant).

I see. I'll add wgLanguageCode, from siteinfo (it doesn't seem to be in SiteMatrix) to the qqq template call. It's usually the same as the subdomain, but not always.

Change 271431 had a related patch set uploaded (by Mattflaschen):
Script for generating a list of human-readable project names

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

There should be some place to at least check the names of the languages. Maybe we could use {{#languagename}} to qqq to produce them, but we should avoid the language code mismatches we have.

Do you know why https://no.wikipedia.org/w/api.php?action=query&meta=siteinfo has language 'nb', but https://no.wiktionary.org/w/api.php?action=query&meta=siteinfo has language 'no'.

My understanding was that the subdomain was wrong, but the language code was correct. But here, the code also does not seem consistent.

In T121936#2036691, @Mattflaschen wrote:

I'll try to clarify: I would like to provide translators the localised language name from CLDR if available. This helps to make consistent translations even though they cannot be used as-is in most languages. We can do that with #languagename in message documentation if we know the language code (if relevant).

I see. I'll add wgLanguageCode, from siteinfo (it doesn't seem to be in SiteMatrix) to the qqq template call.

This is done in patch set 11 of https://gerrit.wikimedia.org/r/#/c/266954/

Do you know why https://no.wikipedia.org/w/api.php?action=query&meta=siteinfo has language 'nb', but https://no.wiktionary.org/w/api.php?action=query&meta=siteinfo has language 'no'.

My understanding was that the subdomain was wrong, but the language code was correct. But here, the code also does not seem consistent.

Maybe T126146: Norwegian messages inContentLanguage look for on-wiki overrides at the /nb subpage, not the root page? Also there is no separate nb.wiktionary.org as far as I can see.

Change 266954 merged by jenkins-bot:
Add a list of human-readable localized project names

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

I've added a section in "Add a wiki" procedure. Feel free to make sure it's understandable and fix/correct otherwise:

https://wikitech.wikimedia.org/w/index.php?title=Add_a_wiki&type=revision&diff=321846&oldid=303488

Change 266474 merged by jenkins-bot:
Display human-readable wiki names for cross-wiki notifications

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

Currently, betalabs displays wiki names in English only - see few examples. Please disregard "Could not retrieve notifications..." messages.

In betalabs we have rather limited selection of wikis - none from the list of manual wikis or special wikis mentioned by @Mooeypoo

Should we keep this ticket active for further verifications when translation will be done?

Etonkovidova wrote:

Should we keep this ticket active for further verifications when translation will be done?

@Mooeypoo, what do you think?

jmatazzoni closed this task as Resolved.Feb 26 2016, 9:39 PM

Verified that translations are working in French and Ukranian:

Ukrainian one is unfortunately wrong - it uses wrong case.

Ukrainian one is unfortunately wrong - it uses wrong case.

Unfortunately the qqq is wrong :( it says that the text is not used in a sentence, only in a heading, but at the top of that screenshot it is used in a sentence.

Thankfully this isn't a problem in Dutch (where I just translated 100 or so of these messages), but it will be in German: the headings should be "Englische Wikipedia" while the sentence at the top should use "auf der englischen Wikipedia" (inflected for dative, and lowercase because language names are not capitalized when used as adjectives, except when at the start of the sentence like in the headings). We'll probably run into versions of this problem for many other languages as well.

Does anyone have suggestions for how to deal with this? Can {{GRAMMAR}} be at all useful here? (I may be way off -- I'm completely unfamiliar with it.) I suppose one option is to have separate version of the messages for use in "from the ..." / "on the ..."- type sentences.

WHAT? How comes I did not notice you wanted to use this in a sentence. In the mockups I saw they were used as headings. The whole point of adding stand-alone project names was to have them independent of any sentence context and that means they cannot be used in sentence context as is. This is the first step.

The second step is to extend GRAMMAR for each language, but that is much more harder as you need to pair a language speaker with a programmer and check all the translations are okay.

Umm, they were not supposed to be used in a sentence, this was just project names (nominative case). Trying to implement this as {{GRAMMAR}} is basically hopeless (you're going to have more special cases than not). Just give up and use them only in headings.

If you need to display projects names in messages like "You have new notifications on whatever Wikipedia", I suppose you could do something like "You have new notifications in 2 projects (English Wikipedia, German Wikinews)".

WHAT? How comes I did not notice you wanted to use this in a sentence. In the mockups I saw they were used as headings.

I now see why that is: the mockup that we posted early on does use a project name in a sentence, but it's Commons, so it doesn't immediately register as a language wiki that needs grammar.

The whole point of adding stand-alone project names was to have them independent of any sentence context and that means they cannot be used in sentence context as is. This is the first step.

@Pginer-WMF : Any ideas for how we could rework the UI to comply with this?

@Pginer-WMF : Any ideas for how we could rework the UI to comply with this?

First, I'd like to understand the details of the issue. Given the following two sentences:

  • "More messages from Catalan Wikipedia and 3 other wikis."
  • "Links were made from Easter Island and 3 other pages to Moai."

Why the former is problematic but not the later (or similar ones we currently use in bundles)?

Would mark the wiki names (in quotes or bold) for the sentence context help to make them more as literals that do not require to "blend" into the sentence grammar?

If that is not possible, until a better solution is found we can skip surfacing one of the wikis (although that is useful to anticipate what is contained in the bundle). In that case, the sentence form would be: "More messages from 4 other wikis."

First, I'd like to understand the details of the issue. Given the following two sentences:

  • "More messages from Catalan Wikipedia and 3 other wikis."
  • "Links were made from Easter Island and 3 other pages to Moai." Why the former is problematic but not the later (or similar ones we currently use in bundles)?

    Would mark the wiki names (in quotes or bold) for the sentence context help to make them more as literals that do not require to "blend" into the sentence grammar?

"Catalan Wikipedia" in this sentence means the actual Catalan Wikipedia. But "Easter Island" means the article about Easter Island, and not the actual Easter Island. (I actually dislike the wording here, I'd prefer "Links were made from the page 'Easter Island' and 3 other pages to the page 'Moai'.", and it's probably often translated closer to this.) If this were not the case, they would be equally problematic. I don't think bolding or other formatting will help.

This doesn't mean it's untranslateable, but it's going to need a smart translator (or at least one who will read the message documentation) and it'll be somewhat awkward.

The ideal translation of the above to Polish would be:

  • "Więcej wiadomości na katalońskiej Wikipedii i 3 innych wiki"

But assuming the "Catalan Wikipedia" is a variable, it could be written as:

  • "Więcej wiadomości: katalońska Wikipedia i 3 inne wiki" ("More messages: Catalan Wikipedia and 3 other wikis")
  • "Więcej wiadomości (katalońska Wikipedia i 3 inne wiki)" ("More messages (Catalan Wikipedia and 3 other wikis)")

I'm not sure if that would work for all languages, though. (Especially if we documented the wiki name messages as only being used in headings, in which case there might be a mess with leading capital letters, for example.) Copious amounts of colons and parentheses is the usual approach to translating things like this ;)

"Catalan Wikipedia" in this sentence means the actual Catalan Wikipedia. But "Easter Island" means the article about Easter Island, and not the actual Easter Island.

Another similar case was with usernames in messages like "Cronopio and 3 others left a message in your talk page". There usernames were representing users. Is there anything that was done in those cases that could be of help here?

"Więcej wiadomości: katalońska Wikipedia i 3 inne wiki" ("More messages: Catalan Wikipedia and 3 other wikis")

The problem with that copy is that it may seem that the items after the colon are the messages.

This comment was removed by Mattflaschen-WMF.

"Catalan Wikipedia" in this sentence means the actual Catalan Wikipedia. But "Easter Island" means the article about Easter Island, and not the actual Easter Island.

Another similar case was with usernames in messages like "Cronopio and 3 others left a message in your talk page". There usernames were representing users. Is there anything that was done in those cases that could be of help here?

Not a problem here (for Polish at least), because "Cronopio" is in the nominative case (it's the subject of the sentence). Equivalent would be "Catalan Wikipedia and 3 other wikis have new messages for you" (this is not exactly what we're trying to say though).

There's an article on Wikipedia about this, not sure if it'll help: https://en.wikipedia.org/wiki/Nominative_case – this is a lot easier if you speak a language where this matters :( and I guess you've been (un)lucky to be born speaking a saner one ;)

A promising option we explored is to not mention the wikis as part of the message, including the list of wikis as part of the excerpt (greyed out in a separate line as we anticipate some of the content in replies). Since that is a separate piece of information it seems it will avoid the issue.

I'll add a mockup illustrating this idea with more detail.

Change 274063 had a related patch set uploaded (by Catrope):
Move list of wiki names from header to body in cross-wiki notification item

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

Change 274063 had a related patch set uploaded (by Catrope):
Move list of wiki names from header to body in cross-wiki notification item

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

Thanks @Catrope for the update (and the screenshots!).
Just a couple of comments about the text copy:

  • For cases where there is only one cross-wiki message, we may want to omit the "More" part (Joe was commenting about this at T114350#1987575).
  • For the case where we have only messages from just one wiki, I wonder if "another wiki" reads better than "one other wiki".
  • For the expanding action, I'd prefer to use "View X messages" instead of "expand" since the user intent is more directly related to checking the messages. The reverse action is ok to be "Collapse".

If any of the above is not trivial we can create separate tickets since they are also not big blockers and can be solved later.

I updated T114350 with a new mockup:

Thanks @Catrope for the update (and the screenshots!).
Just a couple of comments about the text copy:

  • For cases where there is only one cross-wiki message, we may want to omit the "More" part (Joe was commenting about this at T114350#1987575).

We can do that, but could you and Joe hash out what the precise language and conditions should be? The way I read his comment is that we should omit "More" if there are no local notifications, whereas what you're suggesting is conditional on whether there are >1 foreign notifications.

  • For the case where we have only messages from just one wiki, I wonder if "another wiki" reads better than "one other wiki".

Done.

  • For the expanding action, I'd prefer to use "View X messages" instead of "expand" since the user intent is more directly related to checking the messages. The reverse action is ok to be "Collapse".

I'll do that separately, because it's not really related to human-readable wiki names.

  • For the expanding action, I'd prefer to use "View X messages" instead of "expand" since the user intent is more directly related to checking the messages. The reverse action is ok to be "Collapse".

I'll do that separately, because it's not really related to human-readable wiki names.

https://gerrit.wikimedia.org/r/#/c/274162/

We can do that, but could you and Joe hash out what the precise language and conditions should be? The way I read his comment is that we should omit "More" if there are no local notifications, whereas what you're suggesting is conditional on whether there are >1 foreign notifications.

Sorry for the confusion. Joe interpretation is correct. I created a separate ticket for further discussion: T128564: Adjust cross-wiki bundle when it is the only unread item

Change 274063 merged by jenkins-bot:
Move list of wiki names from header to body in cross-wiki notification item

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

Change 274162 had a related patch set uploaded (by Catrope):
Change "Expand N alerts/messages" to "View N alerts/messages"

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

Change 274162 merged by jenkins-bot:
Change "Expand N alerts/messages" to "View N alerts/messages"

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

Checked in betalabs - the screenshots are for uselang=uk (Ukranian) , zh ( Simplified Chinese), and fr (100% complete according to https://translatewiki.net/w/i.php?title=Special%3AMessageGroupStats&x=D&group=ext-wikimediaprojectnames&suppressempty=1#sortable:3=desc)

Seems that what @Pginer-WMF suggested has been implemented:

A promising option we explored is to not mention the wikis as part of the message, including the list of wikis as part of >the excerpt (greyed out in a separate line as we anticipate some of the content in replies). Since that is a separate piece >of information it seems it will avoid the issue.

For uselang=qqx and en

Change 275887 had a related patch set uploaded (by Amire80):
Add Wikimedia Project Names to Main Extensions Used by Wikimedia

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

Change 275887 merged by jenkins-bot:
Add Wikimedia Project Names to Main Extensions Used by Wikimedia

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

jmatazzoni closed this task as Resolved.Mar 14 2016, 7:54 PM

Change 271431 merged by jenkins-bot:
Script for generating a list of human-readable project names

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