Project:Current issues

Jump to navigation Jump to search

About this board

This page is only for discussing issues related to MediaWiki.org site.
To get help with MediaWiki software, ask on Project:Support desk.
Other languages: English  čeština Deutsch français 日本語 Türkçe 中文

Extension:CodeEditor#Configuration where is the 'MediaWiki JS hook' ?

3
Wladek92 (talkcontribs)

Hi all, rereading Extension:CodeEditor#Configuration at section 'JavaScript', it is difficult to understand the text "....by hooking into the [[<tvar|res-loader>ResourceLoader/Default_modules#mediawiki_2</>|MediaWiki JS hook]] <tvar|configure>codeEditor.configure</>."

So can someone reformulate sentence "....by hooking into the ???? " in a more coherent way ? Thanks.

Christian FR (talk) 09:55, 3 April 2020 (UTC)

Ciencia Al Poder (talkcontribs)

I've fixed the link

Wladek92 (talkcontribs)

You are right Jesus but the problem in sentence "It is possible to change the configuration of the ACE editor, by hooking into the MediaWiki JS hook codeEditor.configure." is that if 'MediaWiki JS hook' leads to 'mw.hook' , where this last can lead us to 'codeEditor.configure' ?

Reply to "Extension:CodeEditor#Configuration where is the 'MediaWiki JS hook' ?"
Wladek92 (talkcontribs)
Parser functions {{#arraymap:value|delimiter|var|formula|new_delimiter}}
{{#arraymaptemplate:value|template|delimiter|new_delimiter}}
{{#forminput:form=|size=|default value=|button text=|query string=|autocomplete on category=|autocomplete on namespace=|placeholder=|popup|no autofocus|namespace selector|query string parameters}}
{{#formlink:form=|link text=|link type=|query string=|target=|tooltip=|popup|new window|query string parameters}}
{{#formredlink:form=|link text=|existing page link text=|query string=|target=|popup|new window|create page|query string parameters}}
{{#queryformlink:form=|link text=|link type=|query string=|tooltip=|popup|new window|query string parameters}}
{{#autoedit:form=|target=|link text=|link type=|minor|query string=|reload|tooltip=|query string parameters}}
{{#default_form:form name}}

Christian FR (talk) 12:30, 2 April 2020 (UTC)

Ciencia Al Poder (talkcontribs)

I think this is intended behavior. It displays what parser functions are available and what parameters they accept.

Wladek92 (talkcontribs)

? should it be the place for that here; normally those must be links for unique reference source describing the parameters.Ex: #arraymap ...and so on.

...I'll try to update that.

Ciencia Al Poder (talkcontribs)

The navbox title says "cheatsheet", so it's actually a cheatsheet and not a navbox (although it looks like one)

Wladek92 (talkcontribs)

You are right. Nevertheless starting a search to guess where the reference is (or who will remember to update this sheet when parameters will be modified) is rather heavy. I think to keep as it is with current syntax but making the tags live links to their definitions. This way the definitions will be linked reversely through the related pages menu.

Reply to "Extension:Page_Forms markup text is displayed to the user"
Pppery (talkcontribs)
Shirayuki (talkcontribs)

Extension:Page_Forms/Download_and_installation old Phabricator reference project for Page_Forms

5
Summary by Wladek92

done; new link has been provided.

Wladek92 (talkcontribs)

Hi all, on Extension:Page_Forms/Download_and_installation in first section we make reference in '....go here.' to link on https://phabricator.wikimedia.org//r/p/mediawiki/extensions/PageForms;browse/master/ but there is no PageForms project there in the list of projects.

https://phabricator.wikimedia.org/diffusion/ESFO/browse/master/RENAMED.txt says "This extension has been renamed to PageForms." but where is the projet ?

A good link should be https://gerrit.wikimedia.org/g/mediawiki/extensions/PageForms but syntax of {{git should be changed.

Please, can some one realign 'here' link in Extension:Page_Forms/Download_and_installation....go here consequently ?

Thanks.

Christian FR (talk) 18:25, 30 March 2020 (UTC)

Kghbln (talkcontribs)

I believe the issue was addressed in the meantime.

Wladek92 (talkcontribs)

So ? what should we understand : 1.the URL is ok but the project is not yet created there (where is it actually ?) 2.the project is in another place ... and will go to another place we dont know ?

Kghbln (talkcontribs)

I do not know what you mean with project.

All these links to the code have changed multiple times in the past 2? years. Now there is even a repo an Gitlies. Apparently I lost track when to use what. This is why I usually use GitHub to browse code. Anyhow what was not working was:

<tvar|1>{{git file|action=browse|project=mediawiki/extensions/PageForms|text=PageForms}}</>

So I replaced it with:

<tvar|1>[https://phabricator.wikimedia.org/diffusion/EPFM/ PageForms]</>

I however cannot tell if this is the correct way to do it for the translation system so feel free to improve the link.

Wladek92 (talkcontribs)

Thanks a lot Kghbln. Yes the path works. Im also lost when searching where to find products but I rarely have to get into the code when translating. I understand with such an open system it is not easy to follow each subject and I just try to stick back all pieces with a global redreading and FR translation. Idea is not to leave dummy references since we provide them. They are a help for the reader to go further.

'Project' is the term used in Phabricator when we opened the former link https://phabricator.wikimedia.org//r/p/mediawiki/extensions/PageForms;browse/master/

I will close the topic if no other correction is received.

Pppery (talkcontribs)

I archived Extension:Update earlier today (given that its creator had marked it as historical two years ago. Part of my cleanup following archiving an extension involved archiving its subpages, which I cannot do for Extension:Update/Roadmap because it is a flow board with no content.

I request that an admin deletes the empty flow board at Extension:Update/Roadmap and moves Extension:Update/Roadmap/LQT Archive 1 back to Extension:Update/Roadmap, thus restoring the history of the page as it was originally created and allowing it to be properly archived.

DannyS712 (talkcontribs)

In progress In progress

Puggan.sundragon (talkcontribs)

When the permission error is given, the http-code of the response should be 403, I currently get 200.

Looking around in the code, it feels like OutputPage->showPermissionsErrorPage() should be setting the 403-code.

Puggan.sundragon (talkcontribs)

ops, not a MediaWiki.org issue

Summary by Wladek92

done; pages have been removed from Special:PageTranslation

Pppery (talkcontribs)
Pppery (talkcontribs)

@Wladek92: Could you please attend to this one, given that you did my other sets of requests?

Wladek92 (talkcontribs)

Extension:KML Export/Parser functions // Extension:KML Export/Special pages // Extension:KML Export/Style syntax // Extension:KML Export/Who is using // Extension:KML Export/kml.text //

done; close please when satisfied.

Summary by Wladek92

done; pages have been removed from Special:PageTranslation

Pppery (talkcontribs)

Extensions were archived.

Wladek92 (talkcontribs)

still remain 3 subpages: /en /es /ja

Christian FR (talk) 20:04, 30 March 2020 (UTC)

Wladek92 (talkcontribs)

done; close the topics when you are satisfied. Thanks.

This post was hidden by Pppery (history)

More translatable subpages of archived extensions

6
Summary by Wladek92

done; pages have been removed from Special:PageTranslation

Pppery (talkcontribs)
Wladek92 (talkcontribs)

Same remark : subpages are still present

Christian FR (talk) 20:06, 30 March 2020 (UTC)

Pppery (talkcontribs)

@Wladek92: You misunderstood me; I can't do anything about the subpages until a translation administrator (which could be you) takes action by removing the root pages from the translation system. The way to do that is to "visit Special:PageTranslation, and click 'remove from translation'" (quoted from the Phabricator template for archiving extensions)

Wladek92 (talkcontribs)

tested on Gather/FAQ; ok ?

Pppery (talkcontribs)
Wladek92 (talkcontribs)

Extension:PageSecurity/Note for SE Linux users Extension:Gather/FAQ Extension:OggHandler/Client download Extension:SlippyMap/Cassini/Setup notes Extension:SMW Ontologies/easyrdf.php done.

Christian FR (talk) 20:38, 30 March 2020 (UTC)

Duplicate anchors for translation

17
Summary last edited by Wladek92 20:36, 29 March 2020 4 days ago

Nothing to do for this post; anchors were explained enough and are functional.

Dcljr (talkcontribs)

People who know about translation (of pages at this wiki), please take a look at the discussion at Topic:Vgyp1i2xclcx598p and explain to me (here) why inserting "manual" anchors that duplicate existing section headings, as in this edit is "required" to make translation work. Or, if that is not actually the case, explain that to User:Shirayuki (there).

Ciencia Al Poder (talkcontribs)

For convenience, when linking to sections from translated pages, the English anchor name is used, to prevent it to be translated and then the section title may have a different translation, causing the link to point to a not existing anchor.

This is one way to solve it, but of course has issues. This can be partially solved if we create a new template for this, that only includes the anchor when inserted on a translated page and not on the main one. However, it will still generate duplicate IDs on translated pages where the section title hasn't been translated and defaults to the English one, or by coincidence the translated section is the same in English.

Another option would be to generate specific anchor IDs not in use by section titles, but that won't be obvious when used inside links.

PerfektesChaos (talkcontribs)

Not understanding all implications, but if that template would contain as parameters

  1. English section title
  2. (optional) translated section title

the template might decide whether both are equal, and create auxilary anchor iff they differ.

Then the section might be addressed always by both English or local name, and will be shown with local name, if needed to be provided.

Ciencia Al Poder (talkcontribs)

That would require 2 translation units, one for the section title and another for the parameter of that template. It's like my first proposal, except that it only would cause duplicate IDs in the rare case that the template parameter is translated but the section title is not

PerfektesChaos (talkcontribs)

It does not create any duplicate.

Template programming would compare both English and other, and create auxilary anchor iff (if and only if) they differ (and on non-English page).

For keywords, names, codes it might easily happen that the title is not translatable.

Ciencia Al Poder (talkcontribs)

That would be possible only if the template is responsible of rendering the section title itself, not the current implementation of the anchor template that's rendered outside of the section title.

PerfektesChaos (talkcontribs)

Yes, it is dedicated to some {{Template:TranslationHeadline|english|local}} with optional local translation.

If english not equal to local then add additional id="".

Since the entire thing is dealing with headlines, it may also bear the headline markup by == or <h2> business with further parameter level (2, 3, 4):

  • {{TranslationHeadline|level|english|local}}
Wladek92 (talkcontribs)

Hi all . Having fighted with rereading I confirm the anchor is needed because the reference use it. The reference is generally hidden to the translator so that the anchored text to be always at the same position. More of that the anchor is NEVER translated that means it is outside of the 'translate' sections. Then when you read the documentation you see that in the english text, all sections '==' are automatically anchored (call to template is not explicitly required) and this works in the english text but no longer in the translated text because the section title has been internationalized so that the english anchor must be set manually in the root page. At last we can say anchor can be anything but we use the text of the following section to have an idea of what it is about. Multiple anchor definitions of the same referenced element are allowed and they are here to facilitate the calling from different contributors point of view. No major problem found with Template anchor until now.

Christian FR (talk) 12:42, 26 February 2020 (UTC)

Dcljr (talkcontribs)

Just in case anyone reading this doesn't already know, multiple anchors can be tied to a single section heading using something like:

==<span id="Alternate1"></span><span id="Alternate2"></span>Section==

In this case, "Section" is what is displayed (on, say, the page "Article"), and can be linked to using:

[[Article#Section]]

but these links lead to the same target:

[[Article#Alternate1]]
[[Article#Alternate2]]

This is better than using a template call separate from the heading (and can be accomplished by "subst:"ing the {{anchor}} template inside the heading itself), because it avoids having a template call at the end of one section that actually refers to the next section (as happens if the template call is placed above the section heading) and places the anchor inside the section heading itself, unlike what would happen if a template call was used after the section heading. It also produces clean a page history, because the software automatically ignores the 'span' element(s) in that context. For details, see w:Template:Anchor.

I think this approach would also allow translation to proceed in the usual way — e.g., by using, say:

==<span …></span>Section== <!--T:11-->

Am I wrong?

Wladek92 (talkcontribs)

I have not tried this form, but ok if you confirm. All '==' section titles I have met are 'pure' without any overloading. Thus the contents is isolated from the format and it complies with the recommendations of the site. Format uses CSS or content-external declarations like the anchors set apart). Recommendations also reject the beautify actions or presence of link references in titles. On the other side, when separating contents from format, we immediately identify what is where. Keep also in mind that 'anchor' can reference any part of the html page and not titles only.

Dcljr (talkcontribs)

Just FYI: I think I understand the first two sentences of what Wladek92 just said, but pretty much nothing after that. Since I do not know anything about translation, people should not rely on me to act on any recommendations put forth in this discussion.

Ciencia Al Poder (talkcontribs)

That would be my option 2 of my first message. Note that such spans should be inside <tvar> sections to prevent translators to changing them, and also remove that markup from translations

Dcljr (talkcontribs)

Since this discussion has petered out, I'd like to ask the participants (or anyone else) whether any consensus has actually been arrived at, and if so, what actions have been taken as a result. Have any instructions/recommendations about translation been changed anywhere? Is anyone doing translation differently? If not, then nothing will have been gained by anything said here.

Wladek92 (talkcontribs)
I have answered to your question requesting clarification and dont see what is wrong or should be modified :  "explain to me (here) why inserting "manual" anchors that duplicate existing section headings".

Christian FR (talk) 17:04, 9 March 2020 (UTC)

Dcljr (talkcontribs)

Hmm. You may have tried to answer my question, but I'm afraid it did not serve as "clarification" from my perspective.

Since you say you don't see what is wrong, I will explain in great detail:

The way the "anchor" template is being used on pages like Help:Links results in multiple "id" attributes having the same value in the generated HTML. This makes the HTML invalid.

The current version of Help:Links contains the following duplicate "id" attribute values:

  • Internal_links
  • External_links
  • External_links_to_internal_pages
  • Interwiki_links
  • Interlanguage_links
  • See_also

In the first case, for example, the wiki markup:

{{anchor|Internal|Internal links}}
<translate>
== Internal links == <!--T:3-->

results in the following generated HTML:

<p><span id="Internal"></span><span id="Internal_links"></span>
</p>
<h2><span class="mw-headline" id="Internal_links">[...]</h2>

The fact that there are two different "span" elements having the same "id" attribute value "Internal_links" makes the HTML invalid. If this kind of thing can be avoided (and it sounds like it can be, based on what others are saying here), that would be preferable.

Wladek92 (talkcontribs)

Hi I'm back. I just reread your text and I effectively from W3C it is considered as an error => https://validator.w3.org/nu/?doc=https%3A%2F%2Fwww.mediawiki.org%2Fwiki%2FHelp%3ALinks
On the translated pages the problem disappears and it is why the 'anchor' forced declaration has been used reestablishing the funtionality; here example in FR page:

<p><span id="Internal"></span><span id="Internal_links"></span>
</p>
<h2><span class="mw-headline" id="Liens_internes">

So apart source is not W3C compliant, can you explain which problem this brings to you ? Then we can bring a solution but at lowest costs, that means updating the pages calling this anchor and knowing its is always delicate to start by modifying the templates. On the other side, if it was only a remark, just ignored as proposed by Shirayuki.

Christian FR (talk) 14:54, 29 March 2020 (UTC)

Dcljr (talkcontribs)

I have no further explanation to give. The invalid HTML is the problem. (Along with the suboptimal situation of "having a template call at the end of one section that actually refers to the next section".)