summaryrefslogtreecommitdiff
path: root/uui
ModeNameSize
-rw-r--r--AllLangResTarget_uui.mk2179logplain
-rw-r--r--Library_uui.mk2360logplain
-rw-r--r--Makefile478logplain
-rw-r--r--Module_uui.mk1385logplain
-rw-r--r--README79logplain
d---------prj70logplain
d---------source3308logplain
d---------util76logplain
generated by cgit (git 2.34.1) at 2024-07-14 12:48:22 +0000
Pointed out by an assert when attempting to copy "STANDARD" length characters (8) from "General" (7), which doesn't harm because when not in debug it copied the terminating 0-character. However, the keyword name also needs to be replaced for the locale's resulting format code. Change-Id: Ia5211b307ea44c1ba9c2b86786368355c570d4a2 Reviewed-on: https://gerrit.libreoffice.org/55293 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins <ci@libreoffice.org> 2018-03-02Resolves: tdf#115351 convert boolean equivalent format codes to proper BooleanEike Rathke Because Excel does not know a Boolean number format, BOOLEAN is saved to Excel as "TRUE";"TRUE";"FALSE" with implicit conditions [>0] and [<0]. This when loaded has no boolean property. Then saved to ODF it is loaded as [>0]"TRUE";[<0]"TRUE";"FALSE" with explicit conditions, which has identical meaning. Convert both equivalent format codes to proper BOOLEAN when reading. Locale dependent representations are treated the same, e.g. "WAHR";"WAHR";"FALSCH" Change-Id: I49383d71fce972fdd7ad9b19ce3bc150d02aba62 Reviewed-on: https://gerrit.libreoffice.org/50642 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins <ci@libreoffice.org> 2018-01-25ofz: out-of-memoryCaolán McNamara Change-Id: If1c9ade3268f4ebadfdad771fe3b35641dca210d Reviewed-on: https://gerrit.libreoffice.org/48506 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com> 2017-12-19wrap scoped enum around css::util::NumberFormatNoel Grandin Change-Id: Icab5ded8bccdb95f79b3fa35ea164f47919c68fa Reviewed-on: https://gerrit.libreoffice.org/46339 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Eike Rathke <erack@redhat.com> 2017-12-14Also EnglishKeywords is a NfKeywordTable, not just some vectorEike Rathke Change-Id: I0683fe5f7632e9941f347773c2679af82421bdc4 Reviewed-on: https://gerrit.libreoffice.org/46455 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins <ci@libreoffice.org> 2017-12-14Move GetKeywords() and related from SvNumberformat to SvNumberFormatterEike Rathke ... as especially the keywords are controlled by the current state (locale) of the ImpSvNumberformatScan instance and *not* a property of SvNumberformat. Add a clarifying descriptive comment as well, and outline it's only for the unit tests anyway.. Change-Id: I732918026bf9ffc25db11033d5f10bc2f51e3505 Reviewed-on: https://gerrit.libreoffice.org/46426 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins <ci@libreoffice.org> 2017-12-13German super cow colors, conversion doesn't need a locale switchEike Rathke Change-Id: I86a8bb7d345e707ad45693e997aa18bac7ce8825 2017-12-12Prepare ImpSvNumberformatScan with KeywordLocalization context, tdf#114185Eike Rathke Change-Id: I3942a7de52bcedf491da83407791fcd0080aaf4d