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
Significant change is that footnote marker numbers are changed from
being a CSS-rendered marker to using the rendered "fallback" text.
This could be avoided using the same trick as is implemented for the
reflist: send an inline style variable with the marker content; but
let's only do this if really necessary for user experience.
Template-produced refs are still wrong, but this patch continues to
render them as they come from Parsoid, in the content script.
TODO in later patches:
* reuse of a subref is rendered as '3.2.1' in reader view but '3.0'
and '3.1' in the editor.
* subref numbering is backwards in RTL languages
Bug: T247921
Change-Id: Ieff73769f8ebbc3724f6a9b498487c4e7d09aa2e
Citoid uses placeholder refs to preview where a new/re-used ref
would be added. This also influences the counting and preview in
the reference list for the moment the placeholder is visible.
I can image this that this might become a feature in the future
but for the moment it's a distraction IMO.
Bug: T247921
Change-Id: I5c5e84ae4b183f99530fda0736a58139e9e25d1a
A change to the citoid error message referencing the manual tab is
breaking this test.
Bug: T364595
Change-Id: Ie79be1dbc1b7469cffc380478cf2d24bbe06f470
Also introducing a line break to make the difference a bit more
clear what's part of the message.
We still probably want parsed content and not only text here.
Bug: T247922
Change-Id: If545ab2fe1d807a6bcbcdfc0c3b7de83817554e6
We have a use case in which the client needs to be able to use
language utilities in the content language (footnote markers), so the
data must be wired through. This will only be done in VE, and in the
special case that the interface language != the content language.
Bug: T369613
Change-Id: I2c10e1e36ba594da98e0efa433dd9e1a25aae6fe
I believe this makes the code less brittle, and also makes it a bit
more obvious what these strings are meant to represent.
Change-Id: I0c5cdaa0b94b525ad3e65278ca9bf088f480df40
This is motivated by T367749 where we probably need this code to be
separated. This minor refactoring just moves existing code around
without changing anything. The idea is just to make the concepts more
visible in the code.
Bug: T367749
Change-Id: I765d19fa9cb43a6f8492b707a7ae46ddffe43897
We want it to be possible to turn a <ref> into an extended one after
it was re-used for the first time, not knowing if it later turns out
to be an extended ref.
This should work: <ref name=x/> is a short re-use of a ref that later
turns out to be a <ref extends=… name=x>…</ref>.
<ref name=x></ref> is just another syntax that should behave
identical.
However, it should probably not be possible to turn
<ref name=x>foo</ref> into a subref later because it really, really
looks like a normal ref. Even if the content matches with a later
<ref extends=… name=x>foo</ref> and we usually ignore identical
content, I suggest to block this with a dedicated error message. But
this is for a later patch. This patch here just documents the status
quo.
This patch also contains minor code cleanups that will be useful in
Ia752a7d.
Bug: T367749
Change-Id: Ie38769b36e5c476b96e7af7f03b0fc800b32ba97
This isn't the ideal solution since it doesn't exactly match the
rendered reader view, but it's a reasonable workaround and an
improvement on "undefined" numbering.
Bug: T247921
Change-Id: Ic0d88123d50e2fcb7f25e897280dbfdb6d494501
MVP implementation for adding a warning when editing a reference
that's the extension of another. In the current approach we're
just using the elements .text() like we do when you create an
extended reference.
Bug: T247922
Change-Id: I2fc574152059937b4aa3fc25ee486d363cc809d5
We only need to set some values that are needed by the `insert`
action triggered that then handles the insertion of the ref.
The form to edit or add a reference will never be visible
in the re-use workflow. No need to update that message then.
Change-Id: I710862bdc1bde6a8ce663d863d721cbf075494f0
Includes renaming the method so it's more clear what it's doing.
As preparation for adding the extends warning to the edit pane and
to allow easier identification of parts belonging to the edit
workflow.
Change-Id: If84c5dbdee19c0ebc0a28b50dda93fef3f558c6e
With this patch, we show reflists in a hierarchical view with subrefs
listed under their parent.
TODO in follow-up patch: numbering of subrefs is still incorrect.
Change-Id: Ia82658af72caebd29241b9bd329d236ddc3f1e6d
Pure refactor which shouldn't change output in production. Switches
to interfacing with MWDocumentReferences to get refs in index order.
Temporarily suppresses any subrefs, we only show top-level refs.
Bug: T247921
Change-Id: I9c8347b064173027f436722c87e15e0381c958bd
