/x11_extensions/

(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
* 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
Typos 2016-11-10T21:16:38+00:00 Tor Lillqvist tml@collabora.com 2016-11-10T13:07:12+00:00 a16296429f13b4c23f7327612a3c6fd9947b0f48 Change-Id: I87a63c4b1a13186efa5d0bd807605092197082e0
Change-Id: I87a63c4b1a13186efa5d0bd807605092197082e0
screenshots: add new global make target 2016-08-18T00:39:15+00:00 Armin Le Grand Armin.Le.Grand@cib.de 2016-08-17T07:43:33+00:00 ce6cbf86a5e4e23404a6102d18bb7433a64531d1 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
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
screenshots: add dialog test cases for formula 2016-08-18T00:39:13+00:00 Armin Le Grand Armin.Le.Grand@cib.de 2016-07-22T14:20:34+00:00 8de6321946d08660b23514af528001d9cc976a78 Change-Id: I2fb495dd8603b00127504240e4bec16726c2153f
Change-Id: I2fb495dd8603b00127504240e4bec16726c2153f
RID_FORMULADLG_FORMULA conversion to .ui 2014-06-17T19:42:15+00:00 Szymon Kłos eszkadev@gmail.com 2014-06-16T12:30:55+00:00 0cf14968aacfbf2e51f884242a1c243a645cb7fc Change-Id: I098c9ee9d22ac0401faf7fc6d65e91bf5b4b2bf8 Reviewed-on: https://gerrit.libreoffice.org/9797 Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
Change-Id: I098c9ee9d22ac0401faf7fc6d65e91bf5b4b2bf8
Reviewed-on: https://gerrit.libreoffice.org/9797
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
make l10n buildable separately 2013-11-14T15:45:02+00:00 Bjoern Michaelsen bjoern.michaelsen@canonical.com 2013-11-13T01:12:48+00:00 04dead1c6b9fd8ea24b27d2c5824ae889a2fac66 - 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
- 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