… and make the error message for bad dir="…" shorter and more to the
point.
Now I understand why the error reporting was not done when $text was
empty: the error was actually appended to $text, which messes with
everything else that also works with the $text variable! This even
includes the API. This error message was exposed via the API. That was
certainly a bug.
With this patch, all error checking for the dir="…" attribute is now
done way down, when rendering the <references> section.
Note this also fixes a bug where the dir="…" was *not* rendered when
previewing a section.
Change-Id: I4ab0cb510973ed879c606bfaa394aacc91129854
This fixes a whole bunch of inconsistencies:
* The dir attribute is now trimmed, as most others already are. This is
an actual user-facing change.
* The internal representation is now false in case the value was invalid,
not an empty string any more.
* Null means the attribute was not present. This is now always used,
even in the return values that are meant to represent an error state. No
existing behavior changes.
* The internal representation does not contain an HTML snippet any more,
but the raw value "ltr" or "rtl", or null. Note this might influence the
API, because the API actually exposes the internal representation.
However, we are pretty sure the API is not used anywhere. Even if,
exposing HTML code was most certainly an unwanted and unexpected effect
of the patch that introduced the dir attribute. This does make this a
bugfix, I would argue.
Change-Id: Ic385d9ab36fa0545c374d3d63063028ae4e449d4
This patch does intentionally not touch any file name. Some of the
file names are a little weird now, e.g. \Cite\Cite. These can more
easily be renamed in later patches.
I used https://codesearch.wmflabs.org/search/?q=new%20Cite%5C( and it
looks like this code is not used anywhere else.
Change-Id: I5f93a224e9cacf45b7a0d68c216a78723364dd96
