Remove fuzzy tags

Edited by author.
Last edit: 01:59, 30 September 2022

Problem solved ! The target of the link (that needs the "Wx/xx/" prefix, which should not change) is different from the displayed text (where the prefix is undesired and will be translated).

So you can leave that target link part untranslated, and translate the text after it.

  • Note that this is caused by the fact that translatewiki.net wants us to keep the link, even if it is within a "nowiki", and does not work as a link. But in fact even in that case, the message should provide the expected way for editors in Incubator, that most often, cannot use the reduced fom of wikilinks with the the target page name not being what is wanted in the rendered text of the article. This is a problem of translatewiki.net that overvalidates messages containing wikilinks (effective, or simulated like in this case): it does not accept that we change the target of hyperlinks in translations (even if it is "safe" here).
  • Another way to solve it would be that the message contains a placeholder "$1" for the link target (the underlying app would insert the appropriate target link with a string containing ONLY the target page name, which we could translate isolately, and not containing the double-brackets delimiters.

Note for now that all we can do is to keep the target of the sample hyperlink unchanged, and not use the compact form of the hyperlink (with no pipe), which is most likely never used in Incubator pages (and then should not be displayed as good examples in such messages). In my opinion, even the English source message should not display compact hyperlinks (with no pipe), but always use their in their expanded form (with a pipe) which is what will be almost always used in Incubator pages.

Verdy p (talk)01:28, 30 September 2022

Thank you for resolving this and the explanation.

Eleassar (talk)01:34, 30 September 2022

There are similar problems with hardcoded hyperlinks in this module, such as:

  • Wminc-code-macrolanguage ("The [[wikipedia:$2 language|"$3" language]] is a [[wikipedia:ISO 639 macrolanguage|macrolanguage]], consisting of the following member languages:")

Here the two hyperlinks should be tunable as well by providing a separate translation unit containing only the target page name, pointing possibly to some other article on another Wikipedia edition (or on another wiki, such as Wikimedia MetaWiki) than the indicated article page on English Wikipedia (and possibly in its project namespace locally named ""wikipedia:") describing ISO 639 macrolanguages.

It is assumed that the hyperlink will be resolved from Wikimedia Incubator, where "wikipedia:" is an interwiki prefix; it then points to the English Wikipedia by default, so if we wantto point somewhere else, we need to use the syntax:

wikipedia:(target interwiki code known by English Wikipedia):(optional target interwiki language code):(Translated namespace name):(Translated article name)

So the prefix wikipedia: seems to be invariant in that case.

But Incubator can also resolve itself locally the (target interwiki code known by English Wikipedia): just like the English Wikipedia, so we don't necessarily have to use the wikipedia: prefix (which would work as well if it was written as w:. If we wanted to point to a page on Wikimedia MetaWiki, we could replace wikipedia: by mw: and would not use any (optional target interwiki language code):, but we would certainly have to follow it by a namespace on MetaWiki, and the target page name (whose title would remain in English on MetaWiki) would likely be followed by a /(target translation language code), and possibly by an #(anchor-id)...

For this reason, the target of the link should not be hardcoded, but replaced by a placeholder for a translation variable, as in [[$1|some translatable text]]. The module generating this message would insert its value coming from another separately tunable translation unit containing only a suitable full page name with the necessary interwiki prefixes (wikipedia: is just suggested in the source translation unit in English, but could as well evolve later if there's a more appropriate article than the generic English Wikipedia article describing ISO 639 macrolanguage, notably if there are recommandations for their use as interwiki codes, which actualyl are NOT following ISO 639 exactly but BCP 47, except for a few legacy codes specific to Wikimedia interwikis like "nrm", "simple", "roa-tara", "roa-rup", "map-bms" that must be explained somewhere else...) for targetting any other wiki (and possibly a language subpage code if the page name itself remains untranslated because it is generated by translating a source English page).


Note finally that the 1st hyperlink in that message (given just at start of my message here) assumes a format "$1 language" for the page title describing a given language (but we have to guess how this language is named in English, and there may be additional disambiguation suffixes such as a country name, because different unrelated languages may have the same name in English! as well that prefered name could change, because these names are not unique or there's a strong reason to use another one, because it caused confusion or there were political decisions, or some other consensus).

As well, the ISO 639 standard is not "stable" over time (unlike BCP 47): codes are frequently added, removed (possibly splitted if it was too ambiguous, or just obsoleted because it was added by error in the past, or just merged into another because they are now considered as dialects of another major language with which are mutually intelligible). The classification of languages into macrolanguages evolves too. Only BCP 47 offers stability of these codes which allows them to continue to be resolvable as much as possible (without even being affected by changes of their prefered names or classification), that ISO 639 has never been able to warranty over time. And BCP 47 has an exceelent repository for that, the IANA database of language subtags (there are some additional complexities that are solved by I18n libraries like ICU, possibly taking into account some additional subtags after the primary language subtag, and possibly altering how language fallbacks are resolved).

Also various languages don't have their own article: there are frequent cases where multiple related languages (in a closed group) are described in the same page. To solve that problem, the English Wikipedia offers an alternative title "ISO 639:$1" which will redirect to the appropriate place !

Verdy p (talk)02:11, 30 September 2022