Hello. For example, in the text
abc<ref name=r1/>def ... ghi<ref name=r1 dir=rtl>jkl</ref>mno
the dir parameter is ignored. Could you please create a tracking category for all named ref tags with parameter dir in non-first appearance on the page, so they can be fixed? Thank you.
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Use the dir parameter only from the full definition of a named ref tag | mediawiki/extensions/Cite | master | +40 -0 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Huji | T15673 Supporting directionality for references | |||
| Resolved | Huji | T196827 Use the dir parameter only from the full definition of a named ref tag |
Seems like the PHP code should just be fixed so that dir works correctly even if it is not the first attribute.
Creating a tracking category is arguably more work than just fixing the code properly so you don't need one.
Creating a tracking category is arguably more work than just fixing the code properly so you don't need one.
Sure, @cscott, but you need a category anyway. If you fix this, you'll need a tracking category for all ref tags with name parameter and dir parameter and no "1" parameter. So it takes work for a category, or both fixing and category, not instead.
Another possibility is if you have two ref tags with conflicting directions. How are we handling it right now?
What I meant to say is: how are we tracking these? Do we want that to also be in a category, or do we want to just continue ignoring the subsequent ones?
It is already ignored. I think we really need a category, because otherwise the users will add the dir parameter on wrong place, sure that it works, and leave. With category, we can at least remove it with proper summary, and, who can do this, open the page and decide, move it to the first appearance, or remove completely.
But why did you say "another possibility"? It's exactly what I'm talking about.
I agree with cscott - adding code for tracking category will have SAME code complexity as just fixing it from the begining to take into account whatever dir is provided. (though opposite directions may still require tracking)
@IKhitron The task focuses on dir value not specified on first use, but specified on second use (NULL vs SOMEVALUE). I said "another possibility" because I was talking about the dir value being specified multiple times (e.g. on the second and third usage) in a discordant way (e.g. SOMVALUE vs ANOTHERVALUE).
I see now why it looks different to you, but it completely the same, because the decision is on the first value, ltr, rtl, unspecified.
Change 454708 had a related patch set uploaded (by Arlolra; owner: Arlolra):
[mediawiki/extensions/Cite@master] Use the dir set on the ref from which we're using text
@Arlolra thanks for the patch. It still doesn't resolve the other issue I mentioned, but I will create a new task for it.
Oh, I see T202593. Yes, we've established precedence here, so adding warnings for those other cases should be fine, if so desired.
Change 454708 merged by jenkins-bot:
[mediawiki/extensions/Cite@master] Use the dir parameter only from the full definition of a named ref tag
Hello, @Huji and @Arlolra. Thank you.
But I'm reading these two tasks, and I do not understand something important. Do you mean that from now on a named ref should have the same dir parameter on all instances? Why? Who needs the dir in all instances without text? It's redundunt information and it will disturb the user to write it over and over again, I believe it will be better if the instance with text will be used for direction, and the rest must be without dir parameter at all, throwing an error message if they are. What do you think?