There is no point to bundle it, because
1) it is an old version
2) since LibreOffice 7.5 there are built-in number formats in
Calc with the same functionality (using libnumbertext FWIW)
Change-Id: I8cfb24f7e6f045bd51fea620aca6a61269dba77a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180996
Tested-by: Jenkins
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Do not bundle LanguageTool which is at a 10 year old version (1.7)
while upstream has a lot of new releases (now at version 5.5.x)
It is not bundled by any downstream distributions
so it makes no much sense to keep it integrated here.
Change-Id: Icd2ef151b1b8d0252ffa3db0caaba576f2783fa9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133356
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
There had originally been some back-and-forth among
134ae5da1c "jl154 #162868# remove
basis/presets/bundled/bundled.ini, and create always share/extensions folder",
4c333e8ac7 "jl154 #162868# removing the
package.txt from the extensions folder. Extensions folder will be created in a
different way than installing a dummy file", and
8f4cf9a16e "jl154 #162868# guarantee existence of
extensions folder" whether or not that dummy file was necessary to ensure
creation of the (otherwise potentially empty) $(LIBO_SHARE_FOLDER)/extensions/
directory. That is no longer necessary with gb_Package_add_empty_directory
(though the logic that had to be added to setup_native/Package_packinfo.mk now
is a bit unfortunate, and will need to be updated whenever the list of potential
bundled extensions changes).
(And that dummy package.txt file is apparently not used to track whether per-
user extension information needs to be updated when the contents of
$(LIBO_SHARE_FOLDER)/extensions/ changes. That is rather done by
comparing the status of the $(LIBO_SHARE_FOLDER)/extensions/ directory itself
against user/extensions/bundled/lastsynchronized in the UserInstallation, see
needToSyncRepository in desktop/source/deployment/misc/dp_misc.cxx.)
Change-Id: I5b9956c508288945f32a88afaef57ac0b63dc27f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120081
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Annoyingly the packinfo_*.txt don't support conditionals but we can
work-around that with a little duplication.
Change-Id: Id00a6831effcc63a917fc21d2cd201474fdb559d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109569
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
* Label left-aligned (tdf#132322)
* Long build string cut at 25 chars
* Extra text such as Tinderbox info wraps now at Misc
* UI-Language shortened to just UI
* More padding between about image and text
* Splash screen uses Vegur font
* Splash with small border
* Non-TDF logos have a "Community Edition" text
Change-Id: I1ec31e22052e365f28fe91de3e083252975911c8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93444
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Things break without OpenSymbol font. On the other hand, if you
install just the fonts, but not anything else, you can happily use
the fonts in other applications. So just invert the dependency.
Change-Id: I4c2dbff59699365cba67d3b1c6ade5ec7c2462bf
Reviewed-on: https://gerrit.libreoffice.org/71898
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
...left over from 26b40fcfc6 "Moving mysqlc into
connectivity as a library". (Apparently, for one, a module's Files that don't
exist are ignored, so 8ecf5e1815 "Build fix, make
install: mysql-connector-ooo extension is gone" removing
gid_File_Oxt_MySQLConnector but not
gid_Module_Optional_Extensions_MySQLConnector referencing it didn't cause
trouble; and for another, an empty module is ignored, so there were no
extension-mysql-connector packages generated any more---but better clean up the
junk anyway.)
Change-Id: If598a968dfbbe9b5f16d735e8011e192cbd4178b
Reviewed-on: https://gerrit.libreoffice.org/59669
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.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
Xisco Fauli