Age | Commit message (Collapse) | Author |
|
* 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
|
|
Uwinapi is discontinued.
Change-Id: I063b4d0d8fab2d60de168e960a63b8181158ac01
Reviewed-on: https://gerrit.libreoffice.org/23198
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
Tested-by: David Ostrovsky <david@ostrovsky.org>
|
|
Change-Id: Ida5bdfa06ecd7907305f4f171ca5ab64260d0259
|
|
Change-Id: Ia1e449f8f52e7d353944b8e80f9fc586f1eab2f7
|
|
... years ago in commit e1b51e7beb7f9cfa7b574b9c2a69799e62963a09
Change-Id: I588370796830dc379f6a004ec7e673b020360eb5
|
|
The sc_subsequent_filters_test was failing because of a lock file
because it did not use the unittest configuration.
Refactor gb_CppunitTest_use_configuration so it uses both the instdir
and unittest configuration to prevent such errors.
In case there ever is a test that does not work with the unittest
configuration it should call gb_CppunitTest_use_instdir_configuration.
Change-Id: Ibc00d42f8b6102d50d922f51173120798fa45c6e
|
|
Change-Id: Ia0f0282c4418288adf14997234ef393f44fbdabf
|
|
This required some changes to the framework:
* Init-/DeInitVCL is no longer done per individual test in BootstrapFixture, but
once per CppunitTest invocation in a new vclbootstrapprotector (similarly to
the exisiting unobootstrapprotector). CppunitTests that need VCL now need to
declare gb_CppunitTest_use_vcl.
* For things to work properly, the UNO component context needs to be disposed
from within DeInitVCL (cf. Desktop's Application::DeInit called from
DeInitVCL). The easiest solution was to introduce an
Application::setDeInitHook (where the hook is called from DeInitVCL)
specifically for vclbootstrapprotector to call.
* PythonTests don't (yet) call DeInitVCL; they still hook into
BootstrapFixture's original test_init functionality (to call InitVCL), and do
not make use of the vclbootstrapprotector.
Change-Id: I4f3a3c75db30b58c1cd49d81c51db14902ed68b2
|
|
Unfinished work in progress.
Change-Id: I978755d73630b8653b169a53f937c1332799e22e
|
|
Change-Id: I6f8c6827c00db50184a46f39968f882b944d18d4
Reviewed-on: https://gerrit.libreoffice.org/6967
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
|
|
Change-Id: Ia04eedc6375748505c954e2315a0c5af7afae84f
|
|
There is no reason for the generic UnoApiTest to require Calc
specifically. Calc tests can/should instantiate a Calc instance.
We can create a CalcUnoApiTest for that that inherits from
UnoApiTest; however this does not seem necessary, "make sc.clean"
succeeds.
Anyway, the ScGlobals::ensure mentioned in the comment does not
seem to exist.
This allows us to eliminate some code duplication in tests
that were reimplementing UnoApiTest minus the Calc instantiation.
Change-Id: I37bea9df41e3960df0458fe689cf6c046a243617
|
|
Change-Id: I4c688a4aeedcae56ed6404574bd1bb392d4190cb
Reviewed-on: https://gerrit.libreoffice.org/6311
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ifd32f99f4ab1df1625464c2f269bc85f7283783f
|
|
Change-Id: I44500717109a026d7c71e6494daacbea1f224263
|