It seems that no one resolved this bug.
Another same problem is with the expression "translate links from en to fa" newly appears. The total selection would be
"Toggle the table of contents
Wikipedia
en
fa"
To solve this problem we should first convert "input element" to "anchor element" for "en" and "fa" and then apply the these styles to make them unselectable.

In T347238#9193659, @Umherirrender wrote:

Maybe this is blocked by T170001: Support CodeMirror syntax highlighting on RTL wikis

@Aklapper Yesterday I created an discussion at Farsi community at https://fa.wikipedia.org/wiki/%D9%88%DB%8C%DA%A9%DB%8C%E2%80%8C%D9%BE%D8%AF%DB%8C%D8%A7:%D9%86%D8%B8%D8%B1%D8%AE%D9%88%D8%A7%D9%87%DB%8C/%D9%81%D8%B9%D8%A7%D9%84%E2%80%8C%D8%B3%D8%A7%D8%B2%DB%8C_%D9%82%D8%A7%D8%A8%D9%84%DB%8C%D8%AA_%C2%AB%D9%BE%D8%B1%D8%B1%D9%86%DA%AF%E2%80%8C%D8%B3%D8%A7%D8%B2%DB%8C_%D9%86%D8%AD%D9%88%C2%BB_%D8%AF%D8%B1_%D9%88%DB%8C%D8%B1%D8%A7%DB%8C%D8%B4%DA%AF%D8%B1_%D9%86%D9%88%D8%B4%D8%AA%D8%A7%D8%B1%DB%8C

Hi, please change the background color of table of content from pure white to other colors, it can be the same as background color of other menus. This way the margin of ToC and main article becomes clear,

In Farsi Wikipedia the problem is now resolved and the margin has good distance. Thanks.

Hi, in Farsi Wikipedia the problem is not resolved, and the right margin is still too big! Please see
https://fa.wikipedia.org/wiki/%D8%B5%D9%81%D8%AD%D9%87%D9%94_%D8%A7%D8%B5%D9%84%DB%8C
Thanks,

@Izno If you think that the above behavior is not a bug and this code is implemented correctly currently, please mention some benefit of this existing "not-checking of null" code here. To clarify that this kind of implementation is not a bug of system. Thanks.

@Izno No, this is not the expected behavior of {{{firstName|{{{secondName|}}}}}}. Expected behavior is

if firstName has value (and not only exists) 
  then firstName 
else secondName

I really think that software engineers that many years ago have implemented Wikipedia, were not aware of such an unexpected behavior of synonyms and forgot checking "Nullity in if statement". In my opinion this is really a bug in making synonyms for parameters of templates.

On Farsi Wikipedia we made a temporary css style solution at https://fa.wikipedia.org/wiki/%D9%85%D8%AF%DB%8C%D8%A7%D9%88%DB%8C%DA%A9%DB%8C:Common.css
So in this right-to-left Wikipedia this problem is solved temporarily. But in Arabic Wikipedia (that is also rtl) this style does not applied, and so the signs are clipped. But this problem should not be solved via .css page and needs a global-Wiki action.

To solve this problem, we should apply «padding-right: 6px;» to the class "sidebar-toc-contents". I tested that in the inspector of my browser, and results in showing signs correctly and fully.

Today, the same problem raised again in Farsi Wikipedia, (for example see ToC in https://ar.wikipedia.org/wiki/%D8%AC%D8%AF%D8%A7%D8%A1_%D9%86%D9%82%D8%B7%D9%8A the arrows after rendering are in half.

Hi, I propose that instead of solving this (probably hard) problem, we can erase it and implement another scenario that is probably more appropriate. The better scenario can be placing the ">" ("expand") and "˅" (hide) at the end of that heading. This way, these signs would be placed at right hand side of a heading text in LTR languages and at the left hand side of the heading in RTL languages. So the required space will automatically be provided because there is always some padding at these places.
It should be noted that the scenario of "> and ˅ after text" is much more prevalent than placing them before text, in the contemporary Internet pages.

@Aklapper In my opinion, at least we can use an arrow like → or ► to show current position in ToC.

@Aklapper Although this bug is unsolved for many years in Wikipedia without any attention from readers, is not unimportant and somehow is a disaster.

@Aklapper Would you please add some relevant subscribers to fix this bug? Thanks.

Unfortunately it is not visible now on June 17, 2022, 6:26. It was temporarily, it seems that changes has reverted and scroll bar is hidden now (at the time I written on).

@cjming @LGoto @Jdrewniak Scroll bar is visible now, thanks! But before closing this task, in my opinion, the item "Contents" of ToC is the title of this section, and should be viewed permanently, and placed at the top of section, and outside the scrolling area, and should not be scrolled. This is similar to other scrolling area schemes that the title is outside the scrolling area and not scrolling.

@alexhollender_WMF Because it is the title of this section, and such a title should be permanent to explain the its content. It is like the header of Wikipedia, that is a type of title too and the text "Wikipedia:Village pump (technical)" is displayed when scrolling hides this text from top of a page.

@alexhollender_WMF Yes like that, but the word "Content" should not be scrolled.

@alexhollender_WMF
No, if the TOC is very big, that is, it has many items, then:

• The user confused with this fact that he is in what location of TOC.
• In the case above, the word "Contents" does not appear to the user, and it is not clear that what is this space.

Please see TOC in the page https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical) and test the above items to see what I mean. I discussed the above problems in that Village pump too. Thanks.

Hi, in my opinion table of contents in the new 2022 vector (which exists on the left menu bar) should have an scroll bar. By adding this capability, first, a user can see he/she is in what location of table of contents (near the top or near the bottom of TOC) and second, he can scroll the TOC more easily. I really recommend to add an scroll bar to the TOC by these reasons. Additionally, the word "Contents" should be outside of this scroll bar, and should not be scrolled at all, i.e., it (the word "Contents") should be displayed unrelevant to this fact that we are in what location of an article.

@Jdlrobson Hi, but in my opinion the textual cause of a change in the Wikipedia logo should be strictly tooltipped (for example, the cause of change of the logo for reaching a milestone is tooltipped to clarify that).

The unclickable ToC problem raised again today for me, when using Microsoft Edge Version 101.0.1210.32 (Official build) (64-bit).

@Jdlrobson I agree that sometimes this policy is not implemented in the ordinary case, but in the case of logo change, nearly always a tooltip is shown like google doodle. I think it should be implemented as a "potential capability". I mean it can be implemented as an "option", that is, you "can" show a tooltip or leave it without any tooltip.

@RhinosF1 Farsi Wikipedia community thank you in return.

@Urbanecm Hi again, we are now in April 3 but as I mentioned in the description of request, the logo should be changed back at April 2. I will appreciate you, if you pursuit this change back. Thanks.

@Urbanecm Thanks a lot.

@4nn1l2
سایز لوگو را مربع کردم.

@Urbanecm Under the same file name, I uploaded a new version of that picture that is modified on scale and is thus a square. I think this new version one is appropriate.

@4nn1l2

Following a discussion in https://web.libera.chat/?channel=#wikimedia-tech if anyone disagrees with this logo for Nowruz please write his objection here: https://commons.m.wikimedia.org/wiki/File:Persian_Wikipedia%27s_Featured_Nowruz_Logo_(2022)-3.svg

@4nn1l2 This request was discussed completely in Farsi Wikipedia and there is a full consensus to do this change.
Nowruz is the most important Eid for Iranian people, and is highly important to change logo. All Farsi users agreed to change this logo for about 1 month ago and this convention was regularly done for every year before.

Here an image like https://commons.wikimedia.org/wiki/File:%C3%86toms_-_Translation.svg and a symbol like "↑" convey enough meanings. No text is required here. Additionally a Javascript code must "1-Scroll to top 2-Highlight language lists 3-Open list of languages" on the event of clicking on this image and symbol.
@Aklapper Do you agree? Text free symbols makes it meaningfull in all languages. To do that, is a new task required? Or do you know any existing task relevant for doing that?

In T91683#7338685, @RolandUnger wrote:

For most non-Wikipedia wikis the automatic search is not restricted to the leading section (and sometimes not suitable, too). This restriction was introduced because of a not suitable search algorithm. The result of the automatic search is often not clear for many authors that's why is useful that the authors can autonomously select the page image of interest.

Maybe it can be realized with an additional image syntax argument like [[File:abc.jpg|pageimage|mini|...]].

@Xaosflux Any opinion?

@Aklapper Nowadays such policy is applied to videos in video search engines like YouTube, and Google gallery creates image stories from captured images too.
But here, PageImage story of two images is created, because one says function is a "BlackBox", and one says function is "ManyToOne". Myself in my mind, when I remember a mathematical function, there are 2 images one for each aspect. I think this idea can be completed by a text explainer in the top of each image, that says "Function is BlackBox" and "Function is ManyToOne". Two images are required because each image indicates different aspect of the same concept.
Each image is shown for several seconds, i.e., they are shown in a time interval such that a normal person 1-Understands the picture 2-Can read the image caption. I think a normal person can do this actions in 2 or three seconds successfully.

@Aklapper Timing is a sign for importance of that image to the article's concept. For example, a GIF story for artilce Function_(mathematics) can include 2ms of image "File:Function_machine2.svg" and 1ms an example image e.g. "File:Injection_keine_Injektion_2a.svg".
So timing (in addition to image order) is a factor for indicating the importance of that image to the article concept. Additionally, adding timing capability aids for improving granularity of GIF making function that can be somehow important for new requirements.

In T91683#7334397, @Aklapper wrote:

Hi and welcome @Hooman_Mallahzadeh! Note that having multiple images isn't covered by the user stories of this task and sounds like a separate enhancement request, for a separate ticket.