User talk:Wynndale/language test

From OpenStreetMap Wiki
Jump to navigation Jump to search

Code review

I added a few comments in your code and provided and cleaned version bellow. I also changed the indentation to match what is commonly use on the web ;) 

.LanguageBarDebug
{
    margin : 0;
    background : #f9f9f9;
    border : none;
    padding : 2px; /* This is really a small padding. To give more clarity you should have at least half the font size. */
    font-size : 95%;
    line-height : normal;
    text-align : justify;
}
 
.LanguageBarDebug a.new
{
    display : none;
}

The custom JavaScript is: 

// adds expansion link for language bars
addOnloadHook(function()
{
        // Two issues whith this function:
        // You are writing in javascript something that is the job of CSS. As a result, your code is much larger than necessary
        // Manipulating DOM element is by far the slowest operation in a browser. Avoid it as much as possible
	function expandLanguageBar()	
	{
		var LanguageBar = document.getElementById("LanguagesDebug");
 
		if (!LanguageBar)
		{
			return false;
		}
 
		for (var languageSpan = LanguageBar.firstChild;
			languageSpan != null;
			languageSpan = languageSpan.nextSibling )
		{
			for (var languageLink = languageSpan.firstChild;
				languageLink != null;
				languageLink = languageLink.nextSibling )
			{
				if (languageLink.className == 'new')
				{
					languageLink.style.display = 'inline';
                                        // This only open the language bar but the user might want to close it
				}
			}
		}
	}
 
        // The wrapping function is useless there. You could have kept just the inner function there
        // and removed the parenthesis when setting the onlick
	function expandLanguageBarFunction()
	{
		return function() {
			expandLanguageBar();
			return false;
		};
	}
 
	var ExpandLanguages = document.getElementById("ExpandLanguagesDebug"); // span
 
	// if found a link to expand languages
	var expandLanguageLink = ExpandLanguages.firstChild;
	{ // There is no need to put a block here. Blocks like this are useless in JS as they don't create a scope
		expandLanguageLink.setAttribute('href', '#'); // Not sure why you change the href here. The reason to put a # is that it is short and keep you on the page in case you don't have JS activated. If done, it should be server side
		expandLanguageLink.onclick = expandLanguageBarFunction();
	}
});


Cleaned code: 

.LanguageBarDebug {
    margin : 0;
    background : #f9f9f9;
    border : none;
    padding : 0.5em;
    font-size : 95%;
    line-height : normal;
    text-align : justify;
}
 
.LanguageBarDebug a.new {
    display : none;
}
.LanguageBarDebug.showOther a.new {
    display: inline;
}

// adds expansion link for language bars
addOnloadHook(function() {
    $('#ExpandLanguagesDebug a:first-child').click(function(event) {
        event.preventDefault();
        $('#LanguagesDebug').toggleClass('showOther');
        // The text of the link might need to change as well
    });
});

--Vmeurisse (talk) 11:09, 6 June 2015 (UTC)

Reversing the expansion

Thanks for the effort, that's a clever solution. When the remaining issues are solved, I would be happy to see it adopted.

I just tested it and noticed that clicking on "Other languages" again did not remove the redlinks as I had expected. Perhaps you could add the possibility to reverse the expansion?

Otherwise, it worked entirely as expected for me. :) --Tordanik 12:57, 6 June 2015 (UTC)

  • The cleaned script above does that.--Andrew (talk) 18:29, 6 June 2015 (UTC)
I don’t see much stopping asking to put the CSS and script up. The issue with Firefox and multiple right-to-left languages isn’t a showstopper.--Andrew (talk) 20:39, 9 June 2015 (UTC)
The issue with right-to-left languages was already known in the current version, and that's why they were all listed at end of the lists (those old browsers, not prepared for HTML5 do not currently support the "unicode-bidi:isolate" attribute, but only the former/deprecated "unicode-bidi:embedded" (which is specified before so that it can be replaced by the newer isolates when supported).
To get consistent results, the lists were all sorted by script, in the alphebatic order of the displayed native language name, not in the order of language codes.
This sorting greatly helps users locating their language name (so we don't have to display any language code in the list, which is more compact without them, but more useable than just displaying the language codes).
One note about the Javascript, it should not even have to manipulate the DOM by scanning through links, it should just insert a single class for the container. CSS will do the rest (red links have their own class different from blue links). However hiding red links is not enough if it leaves the leading bullets visible, that's why these bullets have been placed inline inside wikilinks (the small defect is that now those bullets are blue or red and part of the activable link area, you see that when hoverring a link, the active underline is bewow the bullet, the following space, and the language name).
The alternative solution is to not store the bullets and the following space in the DOM as text elements, but have these bullets generated by CSS, before the link itself, they will be displayed if the HTML link itself is visible
A solution for that is to used ":before" selectors to static bullets using static text in CSS directly (but :before insertions are not supported by lot of browsers)
Or to use contextual selectors through successive elements, such as (names of classes are decriptive, not the actual names):
"DIV.languagebar.class-for-hidden-redlinks A.class-for-language-link.class-for-red-link>SPAN.class-for-bullet {display:none}"
which will leave visible a bullet AFTER each visible link, including possibly one at end of the list.
Or better (with the intended semantic):
"SPAN.class-for-bullet<DIV.languagebar.class-for-hidden-redlinks A.class-for-language-link.class-for-red-link> {display:none}"
Using such contextual selectors, bullet separators must still be part of content of the page in the DOM, they won't be generated by CSS. But they will remain outside the wikilinks and of the generated HTML links.
The technic using :before text is used on Wikipedia for showing lists of categories or horizontal navboxes (they just use UL/LI elements and they tweak the presentation of bullets).
Finally, there are too much styles in the generated page. If possible we should only have to generates elements in Wikicode specifying only a single class such as
<dt class="bullet">bullet </dt><dd class="languagename">[[wikilink|native language name]]</dd> for each language or just
<li class="languagename">[[wikilink|native language name]]</li>
— Verdy_p (talk) 03:58, 7 March 2016 (UTC)

Testing this out on a test wiki

Sorry you asked me to look at this ages ago but I've just got around to trying this out. I wanted to test it out on a test install of mediawiki. Installing mediawiki is an easy thing to do. The surprisingly difficult bit seems to be dealing with a massive tree of interconnected wiki templates! But I had a stab at it last night. I did the following:

  • I installed mediawiki afresh.
  • I've copied dozens of templates into my fresh wiki from this one, one-by-one. Template:Languages and (hopefully) all its dependencies.
  • I set up some language namespaces on there DE FR ES IT NL RU JA plus their talk namespaces. Hopefully matching the ones we have here.
  • I took an example page "Software" and copied that onto there along with its translation pages.

That all seemed to work. I was eventually able to reproduced the "current" language bar template running on my wiki and working as expected. See previous version of the 'Software' page there

So then....

The result! : http://harrywood.dev.openstreetmap.org/testwiki/index.php?title=Software

Well so far it didn't work, but there was quite a lot of things to put in place for this test. Maybe you can see what I've done wrong.

-- Harry Wood (talk) 23:32, 16 February 2016 (UTC)

I have updated User:Wynndale/Languages to fix problems when used from the main namespace.--Andrew (talk) 20:15, 17 February 2016 (UTC)
Alright! I've copied that into place, and it looks like its working!
I wonder what other awkward cases we should test on there. That Software example covers a few different things. redirects etc.
-- Harry Wood (talk) 21:59, 17 February 2016 (UTC)
Check:
The mobile interface with MediaWiki::Mobile.css andMediaWiki::Mobile.js updated.
A page from Category:Pages with too many expensive parser function calls doesn’t populate that category.
A page in a language without its own namespace (but the same name as the English page) works with the default template without any arguments.
A category page works with the default template without any arguments.
--Andrew (talk) 07:37, 18 February 2016 (UTC)
Oh one basic thing I didn't test before. I put used the new template on the (english) 'Software' page but I didn't try it on the translation pages. That worked OK for the basic case NL:Sofware but... setting it on the RU page with an alternate name passed in a a parameter... seems to have thrown up an error.
Testing a page in a language without its own namespace... I created 'Ca:Software' catalan translation. All seems to work fine.
For a category page, it maybe has a few problems still. on Category:DE:Portals I tried your template without any params. Doesn't seem to pick up on the other pages. On Category:FR:Portals I tried with the same params it used to have. It works better although for some reason 'English' isn't a link.
-- Harry Wood (talk) 17:05, 18 February 2016 (UTC)
Tweaked again.--Andrew (talk) 19:38, 18 February 2016 (UTC)
OK, but which problem did that tackle? Would it be easier if you could edit my test wiki directly? I'll make you a user on there, then we can copy the template back here when it all seems to be working -- Harry Wood (talk) 21:42, 18 February 2016 (UTC)

Has the test wiki got string functions enabled? I’m using {{Langcode}} to distinguish Ca:Software (base Software) from Key:highway (base Key:highway) and it needs #pos.--Andrew (talk) 14:37, 21 February 2016 (UTC)

Ah no it didn't, but it does now! Sorry. There may be other misalignments like that, but looks like it's close to working.
Looking perfect on Category:Portals. Just a little glitch left on Software for the not-real-namespace pages.
-- Harry Wood (talk) 23:50, 22 February 2016 (UTC)
Ready to risk changing global style sheets and script yet?--Andrew (talk) 00:03, 28 February 2016 (UTC)

OK none baseline DONE. The CSS and JavaScript are in place! -- Harry Wood (talk) 01:13, 29 February 2016 (UTC)

And I see you're testing it out on the Software page here now. All working ok? -- Harry Wood (talk) 10:56, 29 February 2016 (UTC)
Note: #pos and substring extraction was not available on this wiki, that's why we still needed the "ns=" parameter.
But be careful: not all colons in page titles are actually language prefixes!
But since #pos and #sub are available here, Template:Langcode attempts to match what is probably a language code prefix, it has to take care of some known exceptions (such as "Key:", "Tag:" or "Way:" on this wiki) and it only considers colons at specific positions (language codes have a small set of acceptable lengths).
The various cases are tricky to parse
Ideally, this wiki should have not used any prefix for language codes, but only subpages in suffix (like on Commons).
This would also have greatly helped using templates.
May be we could change the convention, by using prefixes only on article spaces (main namespace for English and most languages, other dedicated spaces for articles in for DE,ES,FR,IT,JA,NL,RU), but suffixes on other namespaces (including user pages, templates, and all their associated talkspaces), but this would require a bot to rename and redirect many pages before changing the logic of Langcode and many templates or pages that still assume prefixes).
Also it is irritating since long that dedicated namespace have been all capitalized when language codes are canonically only lowercase, it should be simple to convert them to titlecase only (I tried to do that a couple of years here, but someone did not understood the issue and stopped that. So the 7 languages have remained in capitals; it's not dramataic for their article space or talkspace but it is inconsistent for other namespace, if we want to have the languagebar working correctly) — Verdy_p (talk) 04:03, 7 March 2016 (UTC)

Translate

It's a bit sad to see so much work on the obsolete translation system when it was already agreed to start using the Translate extension. Maybe you can poke Firefishy? Nemo (talk) 05:06, 22 May 2016 (UTC)

There's however a difference that does not allow using this extension immediately: this wili uses prefixes, and the extension was developed to use suffixes. This would require some cook hook to do that, but anyway this still does not solve how we find all translations from a given page (except those that would be translated with this tool, which works by updating the lists of languages using a background bot, but that only looks for pages that are submitted to the translation tool).
The other problem is that this tool still assumes that the source language is only English when it is not suffixed (or prefixed here): there's still no way to submit a new source in another language, and still no way to swtich the source by making another language editable.
The final problem is that most translations in this wiki contain lot of specificities, most often by location. In this wiki we also have lot of pages that will never be translated to English (many pages about projects in German only, and some other regional languages, or pages about the local work of some chapter or group, that may need the translation tool, but not for English: it will never be their priority, and we have not enough people on this wiki to make all the translations to English that would be necessary with a level sufficient to make it a source that should not overwrite the existing pages written better in another language).
Finally bugs in the Translate tool are there since long. So it would be useful for very few pages on this wiki.
What we need in fact would just be to increase the number of "costly parser calls" allowed, but this wiki runs on a much smaller server, with less capacity than Wikipedia or Commons. These parser calls are in fact not so costly (what is really costly is transcluding too many pages as the expansion explodes the number of parsed nodes). But testing the existence of even 200 pages is not slow, it is in fact already performed by MediaWiki when it parsed any wikilink to know if it must render it in blue or red !). That limit in #ifexist calls in obsolete and should even be dropped from MediaWiki (we have better limits in terms of inclusion sizes) ! Even MediaWiki maintains a cache for not testing the existence of the same page multiple times when rendering some page, and between too distinct pages being rendered, there's also a cache in memory to avoid repeated SQL queries or filesystems serches and I/O. — Verdy_p (talk) 07:39, 22 May 2016 (UTC)
Final note: there's still several bugs in the Javascript that hides red links:
  • its DOM selectors are not enough selective
  • it requires putting the separators between languages within the (red) link to hide
  • it requires javascript on the client, but this is not always the case (notably on mobiles)
My opinion is that we should better install an extension hook on the server side that would generate the language bar with much less work, using the prefix index of MediaWiki (or the existing cache of the local search engine that indexes page names, and that can be tuned to detect the language prefixes in page names). But on this wiki we would need a suffix index (pages with names ending by ":English page name") to get a fast list of all existing prefixes and check the format of these prefixes if they match an accepted language code format).
Note also that not all namespaces in this wiki use prefixes, there are some namespaces not using any prefix or suffix at all (notably File:/Media: as it is borrowed from Commons that does not have this naming convention and that also has no subpages in these namespaces), or using suffixes (MediaWiki: for UI translations accessible via "int:"; some pages in "Help:" comming from MediaWiki documentation or documentation of extensions).
Prefixes also should not be used in "User:" space and "User talk:" space, only suffixes (but there are users that have created such prefixed pages out of their own user namespace). I will probably tweak some code to use suffixes in user pages (and later those pages will be moved in their subpages, but for these users the transition will be handled using temporarily a separate language bar, or using the classic method where they will transclude a list of links to their translated pages, lsit s that they'll maintain themselves: the language bar will no longer work in their user pages).
But may be this wiki should transition to use subpages everywhere: we'll drop the unnecessary dedicated namespaces, and all languages will be using lowercase: a bot could perform that by moving pages, and adding a "sub=1 parameter in the Languages template inclusion. — Verdy_p (talk) 08:00, 22 May 2016 (UTC)
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=User_talk:Wynndale/language_test&oldid=1320412"