Copy a single world from the Impress bugdoc to Writer, number of
paragraph styles increase from 126 to 221, while only +0 or +1 are
expected.
It seems the problem is that the editeng doc of the shape refers to all
styles of the masterpage and we write the style table before the
content, so we export all styles to be on the safe side.
Fix the problem by iterating the paragraphs of the selection in the
"copy" (not "export") case, assuming that typically the selection
doesn't refer to all available styles in the document, and the number of
paragraphs in a shape is not a large amount.
An alternative would be to limit the style import on the RTF reading
side, but not producing those not needed styles in the first place looks
superior.
Change-Id: I43e4c542e530ff6422357a28399718e89fdbabe9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169251
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
* 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
For some reason on Windows the linking fails with 'one or more multiply
defined symbols found' error.
Change-Id: If2af0822a837665e8f0a31d04cd42bf4d1f054f0
- 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
LookupTree is a tree structure for fast autocompletion lookups.
Additionally the tree structure stores word probabilities, so each
autocompletion request returns a result with highest probability.
LatinLookupTree is an implementation which was designed to be even
faster and more efficient latin text, however it works with any kind
of unicode strings.
The tree structure was coded by Nico Weyand, Unicode strings support
and conversion to Libreoffice code structure was done by me.
Change-Id: I6549ee45d0952407b8a070f30ed0598fcb420aa7
Miklos Vajna