Page MenuHomePhabricator

tpt-languages-separator message is inconsistent between languages
Closed, InvalidPublic

Description

See code search: in all languages, tpt-languages-separator is defined as  • ... except for French, which instead defines it as  • . Both   and   are the non-breaking space, but one or the other should be chosen and then stuck to for consistency.

Event Timeline

@Dinoguy1000: Does this create an actual real problem? Or is this just an abstract wish for consistency?

And was this reported in Phabricator intentionally? We do not maintain translations; that is up to translators on translatewiki.net. See https://translatewiki.net/w/i.php?title=MediaWiki:Tpt-languages-separator/fr&action=edit and https://translatewiki.net/w/i.php?title=MediaWiki:Tpt-languages-separator/fr&action=history for who to potentially contact.

It's an abstract wish, yes, if you want to put it that way. =)

Aah, sorry about that, it never crossed my mind that this should be reported on Translatewiki.net rather than Phabricator; I've never contributed to TWN, or (to be perfectly honest) even looked at it very much. I've closed this as invalid in light of your pointer. =X

I probably should not have written "just" in my previous comment - I'd also appreciate consistency. Sorry for that!

Thanks for potentially taking this to twn. :)

I ended up taking this to Verdy_p's Meta talk page, since I couldn't figure out how to leave a message on TWN (I'm assuming it requires you to make some translations first, but I'm not a translator by any measure, so that's pretty well out for me), in case you'd like to follow this at all. I'm not quite sure what to make of his response, though... it sounds like a decision imposed by Lua module processing?

Indeed. I interpret it as if there was a reason five years ago (related to Lua) and that they are not sure if that reason still exists.

I'm wondering if there is a task (with 1) clear steps to reproduce, 2) expected outcome, and 3) actual outcome, all in separate sections) which covers the problem that Lua cannot handle named entities. I guess that @Verdy_p should know best?

I searched for open and closed tasks for a number of variants of "(lua|scribunto) named character (entit(y|ies)|references?)" and didn't see anything particularly close to the situation @Verdy_p described, though admittedly my search-fu could just suck. =)

Unfortunately I was cited for a single edit made 5 years ago (not invalid
at that time and not conflictin with any one as it had no prior history).
I cannot remember exactly the reason why I used " " in that case when
other languages used (most probably later) " " (which is also
unexplained).

But yes I've seen situations in Lua where the use of entities could fail in
that Lua module (the same reason that many Lua modules may fail if their
parameter contain a "<nowiki/>" because Lua is called after only the
expansion of templates, but before the actual parsing of the genated wiki
content (after Lua modules have returned the wiki content).

Some Lua modules take into account this situation by preparsing (often very
partially) their parameter values, if there are non significant differences
in them. But many Lua modules never do that (they just expect that Meiawiki
will have "trimmed" the values in named parameters, and left all others
unchanged).

Le dim. 23 juin 2019 à 16:27, Dinoguy1000 <
no-reply@phabricator.wikimedia.org> a écrit :

Dinoguy1000 added a comment.

I searched for open and closed tasks for a number of variants of
"(lua|scribunto) named character (entit(y|ies)|references?)" and didn't see
anything particularly close to the situation @Verdy_p
https://phabricator.wikimedia.org/p/Verdy_p/ described, though
admittedly my search-fu could just suck. =)

*TASK DETAIL*
https://phabricator.wikimedia.org/T226312

*EMAIL PREFERENCES*
https://phabricator.wikimedia.org/settings/panel/emailpreferences/

*To: *Dinoguy1000
*Cc: *Verdy_p, Aklapper, Dinoguy1000, abi_, Taiwania_Justo, Nikerabbit,
KartikMistry

In act it's up to each Lua module to determine which parameter values they
consider as equivalent, so that they will first canonicalize them.

MediaWiki itself does not trim or compress all whitespaces, or HTML
comments, it will just have expanded template transclusions within
parameter values and transmitted their output "as is" in parameter values.

As well MediaWiki will not normalize the wikitext input in any NF[K]C/D
form, will not have replaced numeric or named character entities, will
wtill not have converted the wikisyntax and HTML code, will not validate it
at all (all this comes long after the expansion of #invoke calls and all
other templates transclusions. jsut before the final validation sage and
conversion to HTML/CSS, or generation of templatestylesheets...

It's up to each module to determine if they need to fully parse the
wikisyntax of parameter values (If they do that, they can also selectively
use the context of such expansion within one of the parent frames...), then
perform trimming, whitespace compression, or filtrering of insignificant
characters, Unicode normalizations, casefolding, or numeric evaluation
before performing the rest.

Le lun. 24 juin 2019 à 19:46, Philippe Verdy <verdyp@gmail.com> a écrit :

Unfortunately I was cited for a single edit made 5 years ago (not invalid
at that time and not conflictin with any one as it had no prior history).
I cannot remember exactly the reason why I used "&nbsp;" in that case when
other languages used (most probably later) "&#160;" (which is also
unexplained).

But yes I've seen situations in Lua where the use of entities could fail
in that Lua module (the same reason that many Lua modules may fail if their
parameter contain a "<nowiki/>" because Lua is called after only the
expansion of templates, but before the actual parsing of the genated wiki
content (after Lua modules have returned the wiki content).

Some Lua modules take into account this situation by preparsing (often
very partially) their parameter values, if there are non significant
differences in them. But many Lua modules never do that (they just expect
that Meiawiki will have "trimmed" the values in named parameters, and left
all others unchanged).

Le dim. 23 juin 2019 à 16:27, Dinoguy1000 <
no-reply@phabricator.wikimedia.org> a écrit :

Dinoguy1000 added a comment.

I searched for open and closed tasks for a number of variants of
"(lua|scribunto) named character (entit(y|ies)|references?)" and didn't see
anything particularly close to the situation @Verdy_p
https://phabricator.wikimedia.org/p/Verdy_p/ described, though
admittedly my search-fu could just suck. =)

*TASK DETAIL*
https://phabricator.wikimedia.org/T226312

*EMAIL PREFERENCES*
https://phabricator.wikimedia.org/settings/panel/emailpreferences/

*To: *Dinoguy1000
*Cc: *Verdy_p, Aklapper, Dinoguy1000, abi_, Taiwania_Justo, Nikerabbit,
KartikMistry

@Verdy_p: Please remove unneeded full quotes when replying. Is there is a task (with 1) clear steps to reproduce, 2) expected outcome, and 3) actual outcome, all in separate sections) which covers the problem that Lua cannot handle named entities?

There's NOTHING that Lua cannot handle. But modules have to do that
themselves (and most of them don't!). We have already various helper
modules that allow parsing the wikitext in parameters (in the appropriate
frame context) and convert them to stripped wiki text, or to perform the
full conversion to HTML, cleaning up safe HTML, normalizing, trimming,
compressing, detecting other equivalent values (including normalizing input
numbers), performing case folding.
However I'm not sure that all these steps can be implemented by Mediawiki
(before using the Scribunto hook) or by Scribunto itself:

Scribunto does a very minimal job for detecting named parameters whose
names match a non-zero decimal integer (possibly surrounded by
whitespaces), without requiring them to form an uninterrupted "sequence"
from 1 to N (so it may also pass other parameters keyed by integer numbers,
and wil also pass parameter names as strings that could potentially be
equal numerically to integers. E.g.

"{{#invoke:Modulename|functionname| a | b | 2.0 =x| 2 =y | 5 = z }}"

are passed by Scribunto to functioname(args) as

args = {
[1] = ' a ', --not trimmed
[2] = 'y', -- ' b ' was first set without trimming, but overwritten by

the trimming of 'y '

[5] = 'z', -- ' z  ' was first trimmed,
['2.0'] = 'x', -- numerically equivalent to the integer number 2, but

still passed as a string key, so does not override the value 'y' in [2]

}

but there's no argument[3] and the sequence has only two elements [1] and
[2] (and #args==2). This is consistant with the way MediaWiki processes
parameter names in template transclusions.

Scribunto also passes named with whitespaces-only value, or unnamed empty
parameters as empty strings, not nil, so the key names (or integer numbers)
are still all preserved, including the case where a key could be an empty
string (after trimming it) in "{{#invoke:Modulename|functionname| = }}.

In fact this minimal processing by Scribunto simplifies most Lua modules by
letting them be lazy and not perform any parameter validation. So the
"<nowiki/>" tags in parameters are still there in parameters, as well as
any character entity (the parameters to Lua modules are not necessarily
HTML text or wiki text...)

This causes caveats, notably possible code injection in Lua with some APIs
(and it's easy to pass a parameter that will force the Lua module to
generate an infinite loop, using lot of memory before being stopped by
quota limits, and this can affects widely used templates, but this is not
different from what happens with excessive quota usage when using Wiki
templates, I don't see that as a serious problem, because Lua is still much
faster and economic than wiki template expansions).

@Verdy_p: Asking for a third time: Could you answer my Yes/No question with a "yes" or "no"?
I'm not interested in details, hence I won't read and interpret huge unstructured walls of texts, sorry. (I've explained this before to you.)

You did not ask any question that I would reply yes or no. You just pinged
me with "may be I would know best" so you wanted some explains. That's
exactly what I did.

Le mar. 25 juin 2019 à 11:53, Aklapper <no-reply@phabricator.wikimedia.org>
a écrit :

Aklapper added a comment.

@Verdy_p https://phabricator.wikimedia.org/p/Verdy_p/: Asking for a
third time: Could you answer my Yes/No question with a "yes" or "no"?
I'm not interested in details, hence I won't read and interpret huge
unstructured walls of texts, sorry. (I've explained this before to you.)

*TASK DETAIL*
https://phabricator.wikimedia.org/T226312

*EMAIL PREFERENCES*
https://phabricator.wikimedia.org/settings/panel/emailpreferences/

*To: *Aklapper
*Cc: *Verdy_p, Aklapper, Dinoguy1000, abi_, Taiwania_Justo, Nikerabbit,
KartikMistry

@Verdy_p: Again: Please remove unneeded full quotes when replying.
Thanks. Can you answer my Yes/No question please?

@Aklapper. You still did not ask any "yes/no" question. You just mentioned me with the goal to get explains, and that's what I did (in a structured way even if that not what you expected, but then what you expected is not what you asked for).

It's not a yes/no question, but multiple questions packed into one, for which it is impossible to reply by yes/no.