OOXML writes @ and # as calls and a reference union as a parenthesised
list, so for each of them we need to know how far the sub-expression
under it reaches. CreateStringFromTokenArray worked that out from the
text it had already written. The problem with this is that every pair
it spliced in shifted all the offsets that were still waiting behind
it, so it kept breaking.
Instead of patching the text, OOXMLRewriter builds a second
token array in the shape OOXML spells out and the writer walks that as
it stands. The call names and the parentheses are ordinary tokens, so
there is nothing to splice and no offsets to keep track of. It is the
same trick RewriteMissing already plays a few lines further up, and it
means the input and the output can be looked at side by side.
The # changes place, from behind its operand to a call in front of it,
so it gets an opcode of its own. _xlfn.ANCHORARRAY spells ocAnchorArray
now, and ocSpill keeps the native postfix spelling with no OOXML one at
all, so the postfix form cannot end up in a file by accident. The
import already rewrote the call back into the postfix operator and now
recognises it by opcode instead of by position. The @ stays
ocSingleValue, it is already in front of its operand so only the
parentheses are new.
The OFFSET() literal argument is swapped for the reference error in
the same pass, instead of the writing loop jumping over tokens.
A unit test drives the rewrite on its own: token array in, token array
out, one case per shape. The shapes that end up with nothing to wrap
are in there too - a lone @, one with a missing argument, and text that
never parsed - since those are the ones where dropping a token is the
only change.
Also drop the dead "@" and "#" rows from the OOXML symbol table, the
rows above them already have _xlfn.SINGLE and _xlfn.ANCHORARRAY.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: I63944fb85b5c4388f304f7d94afd0b4f347d7782
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/10155
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 4feac84950f5b524d99e277481de50f7b45a8d2f)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210292
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
* all .ui files go from <interface> to <interface domain="MODULE"> e.g. vcl
* all .src files go away and the english source strings folded into the .hrc as NC_("context", "source string")
* ResMgr is dropped in favour of std::locale imbued by boost::locale::generator pointed at matching
MODULE .mo files
* UIConfig translations are folded into the module .mo, so e.g. UIConfig_cui
goes from l10n target to normal one, so the res/lang.zips of UI files go away
* translation via Translation::get(hrc-define-key, imbued-std::locale)
* python can now be translated with its inbuilt gettext support (we keep the name strings.hrc there
to keep finding the .hrc file uniform) so magic numbers can go away there
* java and starbasic components can be translated via the pre-existing css.resource.StringResourceWithLocation
mechanism
* en-US res files go away, their strings are now the .hrc keys in the source code
* remaining .res files are replaced by .mo files
* in .res/.ui-lang-zip files, the old scheme missing translations of strings
results in inserting the english original so something can be found, now the
standard fallback of using the english original from the source key is used, so
partial translations shrink dramatically in size
* extract .hrc strings with hrcex which backs onto
xgettext -C --add-comments --keyword=NC_:1c,2 --from-code=UTF-8 --no-wrap
* extract .ui strings with uiex which backs onto
xgettext --add-comments --no-wrap
* qtz for gettext translations is generated at runtime as ascii-ified crc32 of
content + "|" + msgid
* [API CHANGE] remove deprecated binary .res resouce loader related uno apis
com::sun::star::resource::OfficeResourceLoader
com::sun::star::resource::XResourceBundleLoader
com::sun::star::resource::XResourceBundle
when translating strings via uno apis
com.sun.star.resource.StringResourceWithLocation
can continue to be used
Change-Id: Ia2594a2672b7301d9c3421fdf31b6cfe7f3f8d0a
Up to now the screenshot creation was added/dependent of
target slowcheck. Since quite some modules have added screenshot
creations now, I added an own target 'screenshot' to allow to keep
current slowcheck and screenshot creation separated
Change-Id: I80a49a0db607edf8e0405672d570f624d29912e7
- this renames the 'almost' module target to non-l10n
- and adds a l10n target which is intended to only build l10n parts of
the product
- packagers should then be able to build l10n and non-l10n parts of the
product independently, thus:
- enable quicker rebuilds
- distribution of load
- updates to l10n without a full rebuild
- security fixes to binaries without rebuilding all l10n
- the new targets are called build-l10n-only and build-non-l10n-only
- note this is not intended to move a concept of split packages
upstream -- while this exsists in distros, the number of test
scenarios for this would explode upstream
Change-Id: Ib8ccc9bc52718d9b0ebbfee76ad93dc29c260863
Conflicts:
filter/Module_filter.mk
see https://gerrit.libreoffice.org/#/c/3367/
and Change-Id: I00c96fa77d04b33a6f8c8cd3490dfcd9bdc9e84a for details
Change-Id: I199a75bc4042af20817265d5ef85b1134a96ff5a
Tomaž Vajngerl