and if grammatical case changes for the word Wikipedia

I'm not sure if https://translatewiki.net/wiki/Grammar has been brought up, so I'll throw it in just FYI.

• Non Wikipedia projects show {{SITENAME}} (Commons, Wikidata, Mediawiki, etc.)

That does not seem to cover cases like fr.wikiversity.org or ar.wiktionary.org, but maybe that's intentional?

@Aklapper you are correct, though it is not intentional! In the current survey, we won't be able to get into wiktionary or wikiversity spaces due to their smaller editor counts so it should not affect us, but it could be something that comes back to us years down the line. The most inclusive way to write this that I could think of would be to say if = Commons, Wikidata, Mediawiki, or other unique site names, then don't include {{SERVERNAME}} rather than the other way around, but I'm not sure if that's possible?

(@aminalhazwani: For the records, that task subtype change was reverted because of the existing Spike project tag on this task.)

(Thanks for the clarification @Aklapper! We are thinking about using only tags instead of task suptype and/or title prefixes because it results in unnecessary information redundancy. For future tasks, is it possible to exclude these automations?)

A couple of links for things that might be useful in this exploration:

• Magic words we could use: https://www.mediawiki.org/wiki/Help:Magic_words
• Parser functions like #ifeq that Amin used: https://www.mediawiki.org/wiki/Help:Extension:ParserFunctions

@TAndic @aminalhazwani what are the sites you would want to show only the site name? Commons and Wikidata? If they are the only two then it will be easier to check for those two for special treatment and leave {{SITENAME}} ({{SERVERNAME}}) for the rest.

I'm asking because then we can do something like:

{{SITENAME}}{{#switch: {{SITENAME}} | Wikimedia Commons | Wikidata = | #default = <nowiki> </nowiki>({{SERVERNAME}})}}

• https://commons.wikimedia.org/wiki/User:JHernandez_(WMF)/sandbox/safety-survey-question-test
• https://www.wikidata.org/wiki/User:JHernandez_(WMF)/sandbox/safety-survey-question-test
• https://en.wikipedia.org/wiki/User:JHernandez_(WMF)/sandbox/safety-survey-question-test

The StringFunctions parser functions that would be very useful for doing partial checks against the SERVERNAME are disabled in all production wikis. So that avenue is a no-go

Also possibly useful, the variable {{CONTENTLANGUAGE}} contains the main language of the wiki, so instead of SERVERNAME that one could be used for a shorter message:

It is also possible to get the localized language name, with {{#language:{{CONTENTLANGUAGE}}}}, for something like this:

In russian:

Keep in mind even if the language is translated you can't make a sentence like:

Although tempting, this doesn't translate at all to other languages, where the language may be a gendered adjective or need other prepositions or language forms, for example in Spanish Wikipedia (español) can't be made español Wikipedia or Wikipedia español, would need to be Wikipedia española or Wikipedia en español.

Any of these changes when translating would be extremely challenging to get right given the wikitext involved, and maybe even impossible in some languages

In the last 30 days, have you felt unsafe or uncomfortable contributing to {{SITENAME}}{{#switch: {{SITENAME}} | Wikimedia Commons | Wikidata = | #default = <nowiki> </nowiki>({{#language:{{CONTENTLANGUAGE}}}})}}?

Thanks for this @Jhernandez !

The sites we don't want a URL with are Wikidata, Commons, and potentially Meta, but we are very very unlikely to get to surveying on Meta any time in the next year or longer. (That I suppose is a question of "Do we include it now just in case, or is it possible to add later?")

For all of the language-specific projects, I would be happy with either {{SERVERNAME}} or using {{CONTENTLANGUAGE}} to generate "(en)". {{SERVERNAME}} to me seems to imply zero ambiguity about which site we mean, but I could be wrong.

Aligned with your concerns, I wouldn't want to attempt working with the full language word in text (ie. "English" "русский") and possibly even just in parentheses; my gut feeling is that it could introduce ambiguity without our knowledge and I worry about risking this working with languages we don't all speak. I am, of course, willing to be convinced otherwise for the parentheses if we can get some confirmations!

In T295751#7513745, @TAndic wrote:

That I suppose is a question of "Do we include it now just in case, or is it possible to add later?"

The messages are easily edited so I think it is better to keep them specific to whatever we are doing at this point. Less complexity for translators.

For all of the language-specific projects, I would be happy with either {{SERVERNAME}} or using {{CONTENTLANGUAGE}} to generate "(en)". {{SERVERNAME}} to me seems to imply zero ambiguity about which site we mean, but I could be wrong.

Aligned with your concerns, I wouldn't want to attempt working with the full language word in text (ie. "English" "русский") and possibly even just in parentheses; my gut feeling is that it could introduce ambiguity without our knowledge and I worry about risking this working with languages we don't all speak. I am, of course, willing to be convinced otherwise for the parentheses if we can get some confirmations!

Sounds good! Just outlining some of the things I found that could be useful in this context 👍

During design review Pau shared with me this list of translations in natural language https://translatewiki.net/w/i.php?title=Special:Translate&group=ext-wikimediaprojectnames&language=es&filter=&optional=1&action=translate. Is this something useful for us?

In T295751#7513889, @aminalhazwani wrote:

During design review Pau shared with me this list of translations in natural language https://translatewiki.net/w/i.php?title=Special:Translate&group=ext-wikimediaprojectnames&language=es&filter=&optional=1&action=translate. Is this something useful for us?

Not immediately relevant to the current investigation, maybe if the question ends up being different per wiki

@aminalhazwani @Madalina I've reached the timebox (approximately) and I've listed the only solution I could find in the description.

• Is that answer enough?
  • Yes: Move to Signoff to resolve
  • No: How should we proceed? Any follow up questions? What is the new timebox?

+1 for moving to signoff. In the meantime I share an update on the parent task T294556: Safety Survey Content and EN Strings.

I think we got the information we were looking for, let's move this to signoff