Mainly leaving out the event handling for the change detection to
still keep it simple.
Also the data flow back for editing the content is still somewhat
opaque because the relevant data is passed by reference. I might
change that in follow up patches so it's more clear.
Bug: T369005
Change-Id: I93b62791ef10bf318697905af8a0c5b5d438fdb5
This patch gives us the same number as will appear in the document,
even when subrefs are present.
Tests could be improved using sinon to check some call assertions
but should be fine for now.
Removed the test for placeholders, because these should be filtered
in MWDocumentReferences.getGroupRefsByParents()
Bug: T370874
Change-Id: I7543a6593308c529bcfbeb0835a7c0882cbf8621
Minor tweak to render the parent as HTML, without fixing anything
else about the layout.
Bug: T370873
Change-Id: I507acf7b86a20d1965bbb32fdc0132b41c929d0c
Some wikis such as eswiki and frwiki prefer to hide the square
brackets by default. Adding a selector-friendly DOM element around
the brackets supports this customization.
This makes it possible to hide the brackets with CSS:
.cite-bracket {
display: none;
}
And it also becomes possible to hide the brackets but make them
appear in copy-pasted article content:
.cite-bracket {
font-size: 0;
}
Bug: T370512
Depends-On: I56b52c399d2c76689fdcb0bc7fd50a8c0ced28fd
Change-Id: Id8684ccee2e6725af2c861da20fc31af1067e614
Now the brackets can be hidden with `display: none;` or made
invisible but appear in copy-pasted content with `font-size: 0;`.
Bug: T370512
Change-Id: I21accb6bf9cdd7f96144cc9a762ff889e48efca4
Some wikis prefer to use Western Arabic numerals rather than the
digit transformation table associated with the content language
script. For these, we should respect the existing
$wgTranslateNumerals configuration settings.
Bug: T370585
Change-Id: I663ae28c5b5d4fdd66b8590eb0b453ec25c2db84
This should cause no user-facing changes.
Now the per-language overrides are expressed as pure data and styling
happens in a single file. We can clearly see the types of
customization that have been made so far.
The CSS styling has also been enhanced, it can now be customized by
setting the CSS variables alone.
Bug: T370027
Change-Id: I2a1bf0365ac0c40991a4fe3f9a2c05dba8b7510c
This is really just a bug. The reuse tab in the reference dialog
always supported keyboard actions (cursor up and down). It was just
impossible to see it because the OOUI base widget we use here doesn't
come with a default styling for this. I suspect this got lost with
some OOUI update years ago. Let's just fix it.
The colors are what OOUI dictates for this situation.
Bug: T360034
Change-Id: I6cfd423830bc0cc86b1aff5dc08a53c49b6e2d9f
Note this actually changes the "subtle" color to be darker. As far
as I understand this is an intentional decision. The old color token
from OOUI is deprecated and intentionally made darker in Codex.
See Ie667c35 and most notably T313502.
Change-Id: I37ad25aa6821d61fe3321e1390d1ccf987075250
These .less files are pointless because these languages have
fallbacks, and the .less file for the fallback is identical. The
behavior on the cluster will not change when we remove these
files. Another file with the same rules will be loaded instead.
I made this patch algorithmically by writing a piece of code that
iterates all existing .less files, checks if the language does
have fallbacks, and if one of the fallback .less files is
identical.
I also updated the existing test case to reflect what's going on.
Change-Id: Iab647956f7bf45e59da1af33ff2b3e81ad016b4c
There is a lot of copy-pasting going on here. I hope the longer file
names also make it more obvious what's actually happening here.
Change-Id: I1cb5fe230cc8e2b90d97f92bc0156110afd6fc79
This is identical with the CSS in ext.cite.parsoid.styles.less that's
active for all languages. The small per-language files should only
contain details that are different from the default.
Change-Id: Ic5470772e3138a7711d006dffa88e727f46bddd6
The internal search index is optimized and expects everything to be
lowercase. This was already done for the text, but not for the name
and group. As far as I can see in the Git history this problem always
existed ever since this code was written.
This fixes an 11 (!) year old bug.
Bug: T53838
Change-Id: I12b3b7c23d34d49b630e9151525409dbddfac24e
When Citoid uses these from the new class they can be removed here.
Bug: T369005
Depends-On: I46fa9fe72b4d095291a01c208cac6c98df2ec088
Change-Id: I1aef5d6a05308191d7d8608902a38c801039af7e
First step to move the UI parts that are relevant for creating,
editing (and extending) a reference to it's own class.
There remains some duplication because of the sub-referencing in
Citoid currently depending on the static properties to build its
own editing interface.
More patches follow, I just wanted to keep it small for reviewers.
Bug: T369005
Change-Id: I8588cde1a54cd505a57a36ed97fc591653c9fb6f
Final step to get the i18n key names align with this extension.
Note that the few community overrides should have a copy of the
keys we're changing here in place so the overrides work for both
variants as long as the deployment is not finished.
Bug: T363156
Change-Id: Idf098d2cb04e8f02247b78e6b4866338eaf02b44
Note that the duplicated search panel is most probably a temporary
solution anyway. We probably want a single search panel that can do
both kinds of "reuse with/without different details".
This is also inconsequential for production. Nothing related to
extended references is currently visible on production.
Added to the otherwise unrelated T369005 for code review purposes.
Bug: T369005
Change-Id: Iedee38dacc01ae59fb1a681e49e655ca91b25b64
Mainly to support the activity tracking use case where we want to
track an active use everytime the user starts anew in this UI.
Bug: T368533
Change-Id: Iecf7e697bbbd637c4a00a44debf615c2351eb390
I found that the code is in some cases not clear with the
terminlogy. Let's start by making it at least more clear what's
related to the "reuse" use case.
Change-Id: I5325489be3b14276b0163d8cb8b84215b55d041e
