Project:Village Pump

This page is only for discussing issues related to MediaWiki.org site.

To get help with MediaWiki software, ask on Project:Support desk.

Hello, I think we should create a new page named Project:AbuseFilter noticeboard to request administrators to create or modify abuse filters.

Is there actual need for that? This page is already available for any wiki concerns (and is specifically mentioned in at least some of the spam filter warnings to address false positives or other issues).

Yeah, I don't think we need one right yet. Maybe if it gets more significant?

On the short page → https://www.mediawiki.org/wiki/Manual:User_signatures?oldid=4336127 the link to access the translated page is sometimes generated using 'll' like for namespaces → {{ll|Manual:Namespace|namespaces}}. and other times using 'Special:Mylanguage' like for magic word in → [[Special:MyLanguage/Help:Magic words|magic word]]

Questions:

1. is it coherent to mix both forms; impact? advantage? ....

2. what is the difference between each one

3. what are the consequeces on translations, on performances...

4. as conclusion, which form is recommended to use and when ?

Thanks.

Christian 🇫🇷 FR (talk) 10:19, 17 June 2022 (UTC)

{{ll}} in general is a shorthand for the Special:MyLanguage/ link, but uses several parser functions and even templates that makes it more costly.

I can see some interesting features added by {{ll}}:

• Backlink tacking (Special:MyLanguage doesn't track whatlinkshere)
• If the link text is omitted, it uses the translated target page name instead.

I don't think I can answer whether it's preferable to use one or the other...

Bonjour,

Voici pour ceux qui le désirent et qui ne seront pas présents sur place le lien vers la page Jitsi sur laquelle je serai connecté lors de la leçon publique prestée dans le cadre de la finalisation de ma thèse de doctorat portant sur le mouvement Wikimédia. En espérant y retrouver certains d'entre vous, je vous invite à ne pas brancher ni votre micro, ni votre caméra sauf à la demande pour éviter la saturation. Les questions seront les bienvenues via le chat et seront traitées en fonction de la gestion du temps qui nous est imparti. Cela commence à 17 h 30 heure de Bruxelles. Une belle soirée à tous et peut-être à demain !

Salut Lionel, 'Demain' c'est quoi dans une semaine ? mets la date stp ou signe ton message.

Christian 🇫🇷 FR (talk) 10:29, 17 June 2022 (UTC)

C'est aujourd'hui vendredi 17 juin à 17h30

When translating messages, I need to see the reference T:xxx of the message in many different situations:

1)to know the context it is used in,

2)to correct any typo left in EN version,

3)to understand and correct misplaced <translate> tags etc.

Then I must open EACH message box and read the number xxx, locate the Id T:xxx in the EN file to acces the right string.

It would be nice to have this T:xxx information displayed together with the message to avoid these redundant useless open actions. Please leave your comment.

Christian 🇫🇷 FR (talk) 10:19, 14 June 2022 (UTC)

You can, instead, search for the English text which (unless it appears more than one time on the page) would point you to the context where it's used.

I prefer there to check directly the T:xxx tag since I know what I'm looking for.

I think this is quite a rare use case, which would just clutter the UI for most users and create maintenance burden. A not very nice solution that however hopefully serves its purpose is putting the following snippet in your common.css/global.css:

.tux-pagemode-edit::after {
	content: attr(title);
	display: block;
	clear: both;
	visibility: visible;
	text-align: right; /* remove this line if you want to have the texts below the English (left) side instead of the translation (right) side */
}

With this, the edit link tooltips (e.g. Edit "Foo/1/fr") appear in page mode without hovering over them. They are somewhat verbose and not copyable, but this is the best solution that can be achieved with pure CSS—and using pure CSS ensures that there are no issues with how it’s updated when messages are filtered, new messages are loaded, the message group/language is changed etc. Since this is a user CSS, there’s no guarantee that it won’t break at some point, but I don’t think it’ll break any time soon.

That's great ! Thank you. Ive tried in common.css. The information appears now, good.

... and it works both for desktop and mobile versions.

Christian 🇫🇷 FR (talk) 08:56, 16 June 2022 (UTC)

.... 🙂 and I even reach messages in Incubator using single global.css on Meta.

Problem 1: On the translated pages, the transcluded screenshots are the EN ones which is not consistent with what the localised text describes and what the user sees on his screen. For example on FR page https://www.mediawiki.org/wiki/Help:TemplateData/fr which describes the interface in french, I see File:Manage template documentation button for TemplateData 2014.png which is the EN interface. Proposal 1: unlock the hardcoded image names where possible (when they hold translatable text) in translate tags in the root file to translate.

Problem 2: naming; are there rules for naming the new derived images ? On COMMONS i see 'File:Manage template documentation button for TemplateData 2014.png' I make a clone 'File:Manage template documentation button for TemplateData 2014 fr.png' with the corresponding FR screenshot but how could we name (syntax) the files of this family ?

Thanks

Christian 🇫🇷 FR (talk) 12:13, 8 June 2022 (UTC)

Problem 1:

Yes, please do this. It is highly desirable to have screenshots in many languages, especially for Help: pages and high-traffic pages.

Problem 2:

AFAIK there are no written rules. My personal preference is to:

• name the extension/software at the beginning
• use English for the file names
• use the same file names for all similar images (just add the language code towards the end)
• put the date/year towards the end

For example, using the file you mention, I would probably write this for the file name:

• File:TemplateData Manage template documentation button 2014.png
• File:TemplateData Manage template documentation button fr 2022.png

Sometimes I might write "fr 2014" and other times I might write "2014 fr". IMO it is best for en to be in the first file name as well, although I tend to forget unless I'm making screenshots in several languages at the same time. IMO the year should be the year that you made the screenshot, which means new screenshots are "2022" even if they look the same as the 2014 screenshot.

Also, most screenshots should get two categories on Commons: one for the software (e.g., c:Category:TemplateData documentation) and one for the language (e.g., c:Category:Screenshots with French).

If you don’t put anything after the language code, and don’t vary the year (if included) across languages, {{LM}} can be used to automatically translate the screenshot if it’s uploaded. This way, translators don’t need to touch (and potentially break) file names, but readers still get a translated file whenever possible.

It looks like that template wants "2014 fr" (with identical names except for the language code).

yes - see my conclusion below. If we remove the year from the name, the advantage is that always the more recent uploaded translated file will be considered.

Christian 🇫🇷 FR (talk) 14:30, 9 June 2022 (UTC)

Ok thanks, sounds good. So I do image transclusion as ->[[{{lm|Manage template documentation button for TemplateData 2014|png|_}}|453px]]. and this means that 'File: .....2014 en' or 'File: .....2014 fr' will be selected automatically -> ok.

Problem: if we include the year in the title i.e change last snapshots into 'File: .....2022' (and this is hardcoded in the root file holding the 'translate' tags) it will suppose that all languages have made their alignement on 2022 which is rarely the case. New images will effectively match 2022 but other snapshots of the same image can still be those of 2014. How to solve that ?

I think I've seen some pages here where images could be translated, but I don't remember what pages and how was that done...

SVG images can be translated (text in the actual image). Was that what you were thinking of? Or were you thinking of pages like Help:VisualEditor/User guide, which change the image to match the language?

Ah, thanks. I was talking about that page. It uses the {{lm}} template, that automatically includes the localized image if it exists.

This approach is easy when marking the page for translation, because translating a file name often may lead to people translating its text, causing a broken image. But on the other hand, it's hard to discover that you can actually upload a translated image (and with what name), and it uses expensive parser functions, which is problematic on pages with many images

Theoretically, the multilingual screenshots for Help:VisualEditor/User guide are being generated by a bot. However, I haven't checked that bot for a couple of years, so I don't know whether it's still working.

a bot ? humm interesting ... I will have a look later on VE FR generated shots, after I complete TemplateData rereading.

Christian 🇫🇷 FR (talk) 20:50, 12 June 2022 (UTC)

It's c:User:LanguageScreenshotBot. It looks like it hasn't run for nearly two years now.

It can only do "empty page" screenshots. It can't do anything showing content that has been typed in the page/in a dialog box.

I have resumed the different positions, please comments considering the following situation:

the initial page is written in EN with 2 snapshots : one for button ("button 2019 en.png") and one for the form ("form 2019 en.png") as displayed in the EN GUI , both files being referenced as 2019 in Commons.

Then this EN page has been updated with new contents to fit 2022 GUI aspect where the button is unchanged but the form contains more items and the author provides in Commons new files "button 2022 en.png"  and "form 2022 en.png".

Proposal:
1. GUI unchanged -> keep old image
If the image is unchanged then keep the old existing reference; as "button 2022 en.png" duplicates  "button 2019 en.png" you must delete "button 2022 en.png" and reference "button 2019 en.png" in the EN root page before translate. This is in charge of the person who modifies the EN root page to keep coherence between text contents and image.

2. GUI modified -> use new snapshot
Replace the 2019 reference by 2022 one;  as the form has changed, transclude now "form 2022 en.png" instead of "form 2019 en.png" in the EN root page before translate. 

3.With translators
The image name must be included into 'translate' tags to warn the translator  that the image has changed.

a. if image has not changed: there is no warning for an obsolete message -> ok, as today, nothing to do.

b. if the image has changed, translator replaces "form 2019 en.png" by "form 2022 fr.png" (or other according to his own language). ThIs makes him conscient that such a snapshot should exists. Two cases : 

b1. If file "form 2022 fr.png" exists on Commons -> ok, nothing to do.

b2. If file "form 2022 fr.png" doesnt exist on Commons, two cases :

b21. The translator creates the snapshot himself and uploads it on Commons; this is easy because GUI appears already in his own language 

b22. If it is impossible because of certain cases (GUI admin, extensions not installed on MediaWiki...), then translator can request for internal help

4. Using template LM and fallback process

What we want is to use image "form 2022 fr.png" when it exists. If not, following fallback should apply: "form 2022 fr.png" > "form 2022 en.png" > "form 2022.png" . We stop there because we know that  "form 2022 en.png"  or "form 2022.png" exist due to the coherence of EN root file.

You should use template LM which already implements these functions. 

Of course we can call directly "form 2022.png" in the root EN source to translate - which makes the process completly automatic - but the translator will not be warned that a snapshot "form 2022 fr.png" must be provided.

5. Problem referencing of the snapshot by year

Sure a reference of the image should exist and it is rather a reference of the version linked to the contents. Here we have chosen the year.It is discriminant enough if the GUI is not modified more often. 

6. Translation via svg update

It is a good idea but is risky:

a. manual processing  :
a1.  I download file "form 2022 en.png" provided by the author 
a2.  I search and translate the corresponding strings
a3.  I upload file "form 2022 fr.png"
a4. -> not reliable due to manual intervention

b.automatic process :
b1. update "form 2022 en.png" replacing the strings by their translated version (from translatewiki.net, wikidata .... ?)
b2. -> not reliable  : manual correction should be possible to correct the gaps.

=> I would prefer the manual capture of screen which reflects direcly what the GUI displays.

Thanks for reading, please leave comments.

Christian 🇫🇷 FR (talk) 07:59, 10 June 2022 (UTC)

Bingo! just tried on -> https://www.mediawiki.org/wiki/Help:TemplateData/fr

it works ! -> FR screenshots appears now (based on those already existing).

Christian 🇫🇷 FR (talk) 20:45, 10 June 2022 (UTC)

Yay!

Once MediaWiki 1.39 gets released, most unmaintained extensions which will not support MediaWiki 1.39 will be archived. Right?

There is no immediate deadline for archiving, it's more of a gradual and incremental process when people find and identify unmaintained extensions.

There are 517 unmaintained extensions.

Do you have a list? How did you determine them?

Well… Category:Unmaintained_extensions.

I think that's a poor dataset to use.

Just for example, the very first one in the category was marked as unmaintained rather than experimental because a request to install it in Wikimedia production was declined, which is… not what "unmaintained" means.

Before the huge amount of work to archive these extensions is triggered, I would encourage interested parties to ping the original authors and either get confirmation that the extension should be disappeared from the Internet, or at least wait a few months of no response before proceeding.

Tracked in Phabricator
Task T299458

There's a proposal posted by @Yair rand on Phabricator said the sitename of this site should be changed. The use of "MediaWiki" for SITENAME could be confusing. (For example, the search box placeholder text on Mediawiki.org currently says "Search MediaWiki" rather than "Search MediaWiki.org".) Of course such change needs a community discussion, so I start one here.

I think this is a bad proposal, and we should leave it as-is.

I don't have a strong opinion on either way, but I think it would make more sense to use "MediaWiki.org" than a plain "MediaWiki", since a lot of pages (if not all) on this wiki that self-references it already use "MediaWiki.org" instead of "MediaWiki". example search.

The site name MediaWiki is disallowed during the installation but could be bypassed by changing $wsSitename on [[Special:MyLanguage/Manual:LocalSettings.php|LocalSettings.php.

I trnslated $1 in a category but the AbuseFilter system prevents me. Please fix the Translation append gibberish filter. Its a false positive, see Special:AbuseLog.

I found the solution, set this topic to Resolved.

Has there been any thought about using the new talk page tools (Talk pages project) on this wiki?

Kind of - see Topic:Wq5fsfui1dlcxvk4. I don't know/remember what the outcome of that discussion was though, @Whatamidoing (WMF)?

The [reply] tool is on by default for all wikitext-based talk pages. I've asked the Editing team in the past to turn on the DiscussionTools Beta Feature by default.

Is your real question closer to "Has there been any thought about making wikitext be the default page model for talk pages on this wiki?" I don't think I would recommend that until we know whether automatic topic subscriptions (the [subscribe] button) is a good thing to enable by default for all users.

That really was my question and I appreciate the feedback.

The page model was originally switched to Flow because the admins kept getting so many requests for "one-off" changes to new pages. It proved to be less work to change the default and freely grant one-off changes back to wikitext (ask any admin you know, or start a thread here whenever you want; if the page doesn't already exist, it's not considered a big deal, and Flow-to-wikitext conversions are possible).

Editing's planning an A/B test for Talk pages project/Notifications. It will hopefully emerge from instrumentation purgatory at the end of this month, run for about a month, and spend another month while the analyst figures out what happened. Depending on the results, the Editing team will make a recommendation. My guess (but data rules) is that they'll suggest enabling automatic subscriptions for newbies and manual subscriptions for old hands. My second guess is automatic for everyone, but with a highly visible opt-out button, which would have to be built. (Also, by this point, it'll be August, which means Wikimania, and nothing else will happen for weeks.)

On the assumption that the local community would first want to have this information plus (assuming the results are favorable) have the [subscribe] button deployed, I think the very earliest that people would want to talk about any changes would be September (October or even November being more realistic, since everything takes longer than it should).

As for the Editing team's role: They'll provide information and recommendations to all WMF wikis, but they weren't consulted on the switch to Flow in the past, and I don't think they expect to be consulted on any switch away from Flow in the future.

I support enabling DiscussionTools here, and moving away from Flow. Thanks.

Can we automate "To users of MediaWiki versions version X and earlier:" sentence in Template:DownloadMediaWiki?