Thu, Nov 9
Ok, I can ask them to create such an entry.
Sat, Nov 4
I'll start a discussion at nowiki if this is in fact an acceptable solution.
Perhaps someone working on VisualEditor/Citoid could say if this is possible?
I try to figure out what is needed to replace the old references that uses raw wikitext with the new form with the template editor. It is not a bug, it is a feature request!
Mon, Oct 30
Fri, Oct 27
The thread has been archived, I've updated the link (w:no:Wikipedia:Torget#Recent unpatrolled). The users comment is
There is a gadget "Språkrekkefølge: Sorter lenker til andre språk akkurat slik du ønsker det. Se bruksanvisning." that might interfere with languages. It is the last one in the section "Innhold". Code at w:no:MediaWiki:Gadget-InterwikiOrder.js
Tue, Oct 24
Sun, Oct 22
There has been a new, and quite confusing vote at nowiki. It can be found at Ny avstemming om nb.wikipedia.org (New voting about nb.wikipedia.org) and the outcome at Avstemning (nb/no) (Voting (nb/no)) with an actual outcome of 23 for the change and 9 against.
Sat, Oct 21
Not sure which navigation popup this is, but it was not noticed by any one involved in the thread at Torget.
I can not reproduce this in versjon 61.0.3163.100 (Offisiell delversjon) Built on Ubuntu , running on Ubuntu 17.04 (64-bit)
OS: Windows 10 Home, Chrome: 62.0.3202.62. The user has tried several browser versions.
Fri, Oct 20
I can ask for specific browser versions, but the user avilena says "I have tried with the latest version of Chrome and Firefox, 64-bit." ("Jeg har prøvd med siste versjon av Chrome og Firefox, 64-bit.")
Oct 16 2017
A stack trace from the user
As I could not identify any problems with the gadgets (sure there are problem with them) I suspect there are something interfering from other user settings. Trying to add and remove each of them will take a lot of time.
Oct 14 2017
Oct 13 2017
Oct 12 2017
Thank you @Jdforrester-WMF!
Oct 11 2017
Sep 29 2017
Sep 27 2017
Sep 25 2017
I wonder if this is at least two very different things, the reference system in use for a ref mark and whether it is inlined.
Sep 24 2017
Sep 21 2017
Closing this as it will imply to break with BCP-47. Choosing "invalid" as per T173602#3613072
Sep 18 2017
Slightly off-topic but the nowiki community would probably accept a move if old URLs will work for some time. I also believe that the community at both nowiki and nnwiki will accept an intercept of page requests for th no-domain a few years into the future, with a manual rerouting of the request to a nn- or nb-domain. The only thing they probably won't accept is broken URLs.
Sep 17 2017
The action it proposes goes against use of public standards, so even if it is possible to do the proposed action it should not be done. I would say it is a clear "decline", but other may have other opinions.
Sorry, but Riksmål is an unofficial deviation from the established standard for Bokmål. You should instead use time to try to identify the actual articles that is written in correct Riksmål at nowiki. Note that Riksmål does not even have a valid language code.
Sep 16 2017
There are 44 articles at nnwiki in Høgnorsk (w:nn:Kategori:Høgnorskartiklar. Those articles are in a very archaic language, even for Nynorsk. I have tried to figure out how many articles there are at nowiki in Riksmål, and the more stringent checks indicate a two-digit number. If I ease the checks I get a three-digit number, and with extremly weak tests four-digits.
Sep 15 2017
As a note to T151301#3291681; the attribute "name" has usually no implication on uniqueness, but "id" has. To assume it is unique within a "group" seems consistent to me. If "name" shall be forced to be unique, then it would be better to change it to "id".
It is a really bad idea to translate tag functions. Actually I believe it is a really bad idea to translate all such markup and programming constructs without a working translator for those constructs.
Sep 14 2017
On T171581#3531014, I believe it is a really bad idea to translate tag functions. Actually I believe it is a really bad idea to translate all such markup and programming constructs without a working translator for those constructs.
The usual wording for an attribute that make an element depend on something else is "for". The attribute "for" would then hold the id of the other element. Because the name is used as the id, if no explicit id exists, then "for" would hold the name. The group must also be specified as the name is only unique within a group. No explicit group attribute imply using a default group.
Sep 13 2017
Sep 1 2017
@Niharika Could it be lazy-fixed after the highlighter has loaded? The user expect it to be there, but he would probably not discover if it were gone for a short while.
I'm on a fairly fast connection, but it has a noticeable latency. It could be the reason why see this bug. It is quite annoying as I must check all the time if the cursor is positioned where I expect it to be.
Aug 30 2017
Aug 26 2017
Seems like this is fixed? Nice! :)
Very nice extension though!
It is something I observed when I logged in with a new account, then it seems like I got logged out each time I tried to save, then got a warning before I could save, but then was returned to a logged in page, and then looped around again. Not sure what caused it, but a hard reload seems to fix it. I have not seen this in production, and because a hard reload fixed it, I would guess some libs and/or cookie are out of sync. (Testing on simplewiki at wmflabs it seems like something is gong on, I'm being logged out and back in.)
Seems like it is working, testpage. Any idea why only some editors observed the problem? I assumed the array was out of bounds, forgot to mention that.
Aug 25 2017
The patch seems a likely fix, but still won't explain why it happens to only some users.
Did a "restore to default settings" and still got the bug.
Changed to "English", still got the bug.
This is a page in the main space on nowiki.
Both my account "jeblad" and "jeblad (bot)" shows the bug.
No bug while writing in your sandbox! That is weird!
There are also another bug, the "try me" dialog box won't go away unless I click the "X".
In Chromium the content in the edit frame disappears when I turn on syntax highlight. Another bug, T174123, and it blocks me from testing this bug.
There are a couple of badly behaving gadgets at nowiki, I would not be surprised if this has something to do with any of them.
Aug 24 2017
Aug 23 2017
- "no" is "norsk" according to Unicode Utilities: Unicode Language Identifers and BCP47, ISO 639-1 (note enwiki as the ISO site has a paywall) and W3schools: HTML Language Code Reference
- "nb" is "norsk bokmål" according to Unicode Utilities: Unicode Language Identifers and BCP47, ISO 639-1 (note enwiki as the ISO site has a paywall) and W3schools: HTML Language Code Reference
- "nn" is "norsk nynorsk" according to Unicode Utilities: Unicode Language Identifers and BCP47, ISO 639-1 (note enwiki as the ISO site has a paywall) and W3schools: HTML Language Code Reference
- external sites can't use the macro code if it is forced to bokmål, ie. they can't be bilingual (one example is Lokalhistoriewiki))
- a revert will make the legitimate use of "no" invalid for bilingual sites like Wikinews (n:Wikinytt:Målnøytralitet-nb), Wikibooks (b:Wikibøker:Språkform), and Wikisource (s:Wikikilden:Hva er Wikikilden?#Språk og oversettelser)
- note that there are also two other projects that abuse the "no" code, Wiktionary and Wikiquote, both should be using the "nb" language code
- a revert will again break the language parser function for the "no" language code
- a revert will break (?) the babel extension (or does this still use its own language names?)
- the site matrix should have three lines for Norwegian, "no", "nb" and "nn", which is a bit awkward
- now it is also inconsistent as several projects using the "no" code when they should have been using "nb"
- cleaning up the macro code would make it possible to use it as a common code in the signature section of Wikibase items
- cleaning up makes it possible to interpret the "no" code properly in the Babel extension, that is "no" imply categorization as user of both bokmål and nynorsk
- simplification within content translation, now "no" is handled as a special case (there are a lot of special cases for "no" in that extension)
- the community at nnwiki don't like that links to nowiki is called "norsk" (the name pair are also commonly called "norsk" and "nynorsk")
- some users at nowiki says they should be allowed to use "no" as the wiki contains both bokmål and riksmål (the later is a private language standard without language code that is almost identical to bokmål)
@Hogne The technical implications for a domain redirect from no.wikipedia.org to nb.wikipedia.org are virtually non-existing. The problem is the code «no» and how it is dig into some very large database tables. Some users add additional non-technical demands that makes it pretty difficult to do any change, not sure what to do with that. The easiest would probably be to neglect all non-technical requests. The reasoning behind this task is invalid anyhow as it stands, as it can't be done without breaking other projects and standards.
Aug 21 2017
This is a request to break with the ISO 639-1 standard for language codes and their descriptions. Such a revert should not be done, because it is wrong.
I wonder if "no" could be used for those cases where the signature is equal for the two language forms. The same could be done for larger language groups, unless the fields are overridden by an exact language match. This would solve a lot of duplicate names.
Aug 20 2017
I tried to tell the people at nowiki that the label is not used solely for them, but several wikis, and that some has a legitimate use of the code "no". Those wikis should not be forcibly named "norsk bokmål" just because a fault at nowiki.
Feature extraction for the classifier I guess. It is quite common to do it like this. Including runaway regexes… :D