summaryrefslogtreecommitdiff
path: root/i18npool
AgeCommit message (Collapse)AuthorFilesLines
2020-09-16Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uStringStephan Bergmann2-6/+6
...from which an OUString can cheaply be instantiated. This is the OUString equivalent of 4b9e440c51be3e40326bc90c33ae69885bfb51e4 "Turn OStringLiteral into a consteval'ed, static-refcound rtl_String". Most remarks about that commit apply here too (this commit is just substantially bigger and a bit more complicated because there were so much more uses of OUStringLiteral than of OStringLiteral): The one downside is that OUStringLiteral now needs to be a template abstracting over the string length. But any uses for which that is a problem (e.g., as the element type of a container that would no longer be homogeneous, or in the signature of a function that shall not be turned into a template for one reason or another) can be replaced with std::u16string_view, without loss of efficiency compared to the original OUStringLiteral, and without loss of expressivity. The new OUStringLiteral ctor code would probably not be very efficient if it were ever executed at runtime, but it is intended to be only executed at compile time. Where available, C++20 "consteval" is used to statically ensure that. The intended use of the new OUStringLiteral is in all cases where an object that shall itself not be an OUString (e.g., because it shall be a global static variable for which the OUString ctor/dtor would be detrimental at library load/unload) must be converted to an OUString instance in at least one place. Other string literal abstractions could use std::u16string_view (or just plain char16_t const[N]), but interestingly OUStringLiteral might be more efficient than constexpr std::u16string_view even for such cases, as it should not need any relocations at library load time. For now, no existing uses of OUStringLiteral have been changed to some other abstraction (unless technically necessary as discussed above), and no additional places that would benefit from OUStringLiteral have been changed to use it. Global constexpr OUStringLiteral variables defined in an included file would be somewhat suboptimal, as each translation unit that uses them would create its own, unshared instance. The envisioned solution is to turn them into static data members of some class (and there may be a loplugin coming to find and fix affected places). Another approach that has been taken here in a few cases where such variables were only used in one .cxx anyway is to move their definitions from the .hxx into that one .cxx (in turn causing some files to become empty and get removed completely)---which also silenced some GCC -Werror=unused-variable if a variable from a .hxx was not used in some .cxx including it. To keep individual commits reasonably manageable, some consumers of OUStringLiteral in rtl/ustrbuf.hxx and rtl/ustring.hxx are left in a somewhat odd state for now, where they don't take advantage of OUStringLiteral's equivalence to rtl_uString, but just keep extracting its contents and copy it elsewhere. In follow-up commits, those consumers should be changed appropriately, making them treat OUStringLiteral like an rtl_uString or dropping the OUStringLiteral overload in favor of an existing (and cheap to use now) OUString overload, etc. In a similar vein, comparison operators between OUString and std::u16string_view have been added to the existing plethora of comparison operator overloads. It would be nice to eventually consolidate them, esp. with the overloads taking OUStringLiteral and/or char16_t const[N] string literals, but that appears tricky to get right without introducing new ambiguities. Also, a handful of places across the code base use comparisons between OUString and OUStringNumber, which are now ambiguous (converting the OUStringNumber to either OUString or std::u16string_view). For simplicity, those few places have manually been fixed for now by adding explicit conversion to std::u16string_view. Also some compilerplugins code needed to be adapted, and some of the compilerplugins/test cases have become irrelevant (and have been removed), as the tested code would no longer compile in the first place. sal/qa/rtl/strings/test_oustring_concat.cxx documents a workaround for GCC bug <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96878> "Failed class template argument deduction in unevaluated, parenthesized context". That place, as well as uses of OUStringLiteral in extensions/source/abpilot/fieldmappingimpl.cxx and i18npool/source/localedata/localedata.cxx, which have been replaced with OUString::Concat (and which is arguably a better choice, anyway), also caused failures with at least Clang 5.0.2 (but would not have caused failures with at least recent Clang 12 trunk, so appear to be bugs in Clang that have meanwhile been fixed). Change-Id: I34174462a28f2000cfeb2d219ffd533a767920b8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102222 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-07Make the OUString ctors taking raw sal_Unicode pointer/non-const array explicitStephan Bergmann1-60/+64
...and in turn add OUString::operator = and OUString::operator += overloads that take a std::u16string_view. Without making the ctors explicit, the operator overloads would have caused ambiguities when called with raw sal_Unicode pointers/non-const arrays, as those can convert to both OUString and to std::u16string_view. But the std::u16string_view operator overloads will generally be useful when changing OUStringLiteral similarly to 4b9e440c51be3e40326bc90c33ae69885bfb51e4 "Turn OStringLiteral into a consteval'ed, static-refcound rtl_String", at which point many existing uses of OUStringLiteral will be replaced with uses of std::u16string_view. Implementing this change turned up a need for an operator = overload for OUStringNumber, which has thus been added. No such need turned up for a corresponding operator += overload, but which can easily be added when the need arises. It also revealed that the operator == overloads between an OUString and a raw sal_Unicode pointer/non-const array were implemented rather inefficiently, creating a temporary OUString from the raw argument. Those have been improved. Preceding commits have already taken care of many dubious or simply unnecessary implicit uses of the now-explicit OUString ctors. This commit makes explicit the few remaining reasonable uses. (And in some cases needed to change variable initialization syntax from using parentheses to using curly braces, to avoid the most vexing parse issue. And needed to explicitly add OUString ctors from char16 const[2] string literal lvalues in a conditional expression in writerfilter/source/ooxml/OOXMLFastContextHandler.cxx that are only necessary because MSVC apparently still insists on doing array-to-pointer decay there.) All of this only affects LIBO_INTERNAL_ONLY. Change-Id: I7ce31162e9be1c3ff3c0bd184a34b535ec56be9e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102098 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-05Simplify comparison between OUString and raw pointerStephan Bergmann1-1/+2
...avoiding the construction of an intermediary temporary OUString, assuming the given `word` will never contain embedded NUL characters. (This change is a prerequisite for making the OUString ctor taking a raw pointer explicit.) Change-Id: I3b500557abb3554e9dfda63ef30b22c6c06c99c7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102084 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-04Make many OUString functions take std::u16string_view parametersStephan Bergmann1-1/+1
...instead of having individual overloads for OUString, OUStringLiteral, and literal char16_t const[N]. (The variants taking OUString are still needed for !LIBO_INTERNAL_ONLY, though. The variants taking ASCII-only literal char const[N] are also left in place.) This nicely reduces the number of needed overloads. std::u16string_view allows to pass as arguments: * OUString * OUStringLiteral * OUStringChar (with the necessary conversion added now) * OUStringNumber * u"..." char16_t string literals * u"..."sv std::u16string_view literals * std::u16string, plain char16_t*, and more A notable exceptions is OUStringConcat, which now needs to be wrapped in OUString(...), see the handful of places that needed to be adapted. One caveat is the treatment of embedded NUL characters, as std::u16string_view(u"x\0y") constructs a view of size 1, while only u"x\0y"sv constructs a view of size 3 (which matches the old behavior of overloads for literal char16_t const[N] via the ConstCharArrayDetector<>::TypeUtf16 machinery). See the new checkEmbeddedNul in sal/qa/rtl/strings/test_oustring_stringliterals.cxx. The functions that have been changed are generally those that: * already take a string of determined length, so that using std::u16string_view, which is always constructed with a determined length, is no pessimization (e.g., there are operator == overloads taking plain pointers, which do not need to determine the string length upfront); * could not benefit from the fact that the passed-in argument is an OUString (e.g., the corresponding operator = overload can reuse the passed-in OUString's rtl_uString pData member); * do not run into overload resolution ambiguity issues, like the comparison operators would do. One inconsistency that showed up is that while the original replaceAll(OUString const &, OUString const &, sal_Int32 fromIndex = 0) overload takes an optional third fromIndex argument, the existing replaceAll overloads taking OUStringLiteral and literal char16_t const[N] arguments did not. Fixing that required a new (LIBO_INTERNAL_ONLY) rtl_uString_newReplaceAllFromIndexUtf16LUtf16L (with test code in sal/qa/rtl/strings/test_strings_replace.cxx). Another issue was posed by test code in sal/qa/rtl/strings/test_oustring_stringliterals.cxx that used the RTL_STRING_UNITTEST-only OUString(Except*CharArrayDetector) ctors to verify that certain function calls should not compile (and would compile under RTL_STRING_UNITTEST by taking those Except*CharArrayDetector converted to OUString as arguments). Those problematic "should fail to compile" tests have been converted into a new CompilerTest_sal_rtl_oustring. Change-Id: Id72e8c4cc338258cadad00ddc6ea5b9da2e1f780 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102020 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-03-Werror,-Wcompound-token-split-by-spaceStephan Bergmann1-1/+1
Between <https://github.com/llvm/llvm-project/commit/ 0e00a95b4fad5e72851de012d3a0b2c2d01f8685> "Add new warning for compound punctuation tokens that are split across macro expansions or split by whitespace" and <https://github.com/llvm/llvm-project/commit/ 0da84535b1e328188efbc1bb697dc7276f9e7d27> "Remove -Wcompound-token-split-by-space from -Wall", Clang 12 trunk emitted such "'::' and '*' tokens forming pointer to member type are separated by whitespace" warnings, so just clean those places up for good even if the warning would not hit out of the box with any official Clang release. Change-Id: Ic58c0da4b3dcce428f5aaa54e13d15299394cf9e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101987 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-02Turn OStringLiteral into a consteval'ed, static-refcound rtl_StringStephan Bergmann1-1/+1
...from which an OString can cheaply be instantiated. The one downside is that OStringLiteral now needs to be a template abstracting over the string length. But any uses for which that is a problem (e.g., as the element type of a containers that would no longer be homogeneous, or in the signature of a function that shall not be turned into a template for one reason or another) can be replaced with std::string_view, without loss of efficiency compared to the original OStringLiteral, and without loss of expressivity (esp. with the newly introduced OString(std::string_view) ctor). The new OStringLiteral ctor code would probably not be very efficient if it were ever executed at runtime, but it is intended to be only executed at compile time. Where available, C++20 "consteval" is used to statically ensure that. The intended use of the new OStringLiteral is in all cases where an object that shall itself not be an OString (e.g., because it shall be a global static variable for which the OString ctor/dtor would be detrimental at library load/unload) must be converted to an OString instance in at least one place. Other string literal abstractions could use std::string_view (or just plain char const[N]), but interestingly OStringLiteral might be more efficient than constexpr std::string_view even for such cases, as it should not need any relocations at library load time. For now, no existing uses of OUStringLiteral have been changed to some other abstraction (unless technically necessary as discussed above), and no additional places that would benefit from OUStringLiteral have been changed to use it. sal/qa/rtl/strings/test_ostring_concat.cxx documents some workarounds for GCC bug <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96878> "Failed class template argument deduction in unevaluated, parenthesized context". Those places, as well as uses of OStringLiteral in incodemaker/source/javamaker/javaoptions.cxx and i18npool/source/breakiterator/breakiterator_unicode.cxx, which have been replaced with OString::Concat (and which is arguably a better choice, anyway), also caused failures with at least Clang 5.0.2 (but would not have caused failures with at least recent Clang 12 trunk, so appear to be bugs in Clang that have meanwhile been fixed). This change also revealed a bug in at least recent Clang 12 trunk CastExpr::getSubExprAsWritten (still to be reported to LLVM), triggered at least in some calls from loplugin code (for which it can be fixed for now in the existing compat::getSubStringAsWritten). A similar commit for OUStringLiteral is planned, too. Change-Id: Ib192f4ed4c44769512a16364cb55c25627bae6f4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101814 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-01cid#1466573 Dereference after null checkCaolán McNamara1-1/+1
Change-Id: Ie8f5c015d32b67ad9148c1d0bb8d73425a5b563a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101827 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-08-30Goodbye O[U]StringView, welcome O[U]String::ConcatStephan Bergmann3-8/+8
O[U]StringView had an odd mixture of uses. For one, it was used like std::[u16]string_view, for which directly using the latter std types is clearly the better alternative. For another, it was used in concatenation sequences, when neither of the two leading terms were of our rtl string-related types. For that second use case introduce O[U]String::Concat (as std::[u16]string_view can obviously not be used, those not being one of our rtl string-related types). Also, O[U]StringLiteral is occasionally used for this, but the planned changes outlined in the 33ecd0d5c4fff9511a8436513936a3f7044a775a "Change OUStringLiteral from char[] to char16_t[]" commit message will make that no longer work, so O[U]String::Concat will be the preferred solution in such use cases going forward, too. O[U]StringView was also occasionally used to include O[U]StringBuffer values in concatenation sequences, for which a more obvious alternative is to make O[U]StringBuffer participate directly in the ToStringHelper/O[U]StringConcat machinery. Change-Id: I1f0e8d836796c9ae01c45f32c518be5f52976622 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101586 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-28tdf#122759 sc: fix Autofilter case sensitivity for HungarianAttila Szűcs1-3/+0
Remove case sensitivity from NON case-sensitive Hungarian collator in i18npool, added by commit 7b1eb6313c0d2621c364df1724c69d28f8267841 (tdf#116666 fix Hungarian sorting). It seems, this doesn't affect Writer, where it's possible to choose case-sensitive sorting, too. Note: Handling of space is still a problem for normal text, i.e. sorting according to Hungarian orthography, see commit 7618490d334409c3fc4167f32732537ef738647f (tdf#123204 hu_HU collation: don't ignore special characters). Co-authored-by: Tibor Nagy (NISZ) Change-Id: I667eb5e22401a7fcef0e6e6111c48ce7d9c4aaf3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101527 Reviewed-by: László Németh <nemeth@numbertext.org> Tested-by: László Németh <nemeth@numbertext.org>
2020-08-28Change OUStringLiteral from char[] to char16_t[]Stephan Bergmann3-5/+5
This is a prerequisite for making conversion from OUStringLiteral to OUString more efficient at least for C++20 (by replacing its internals with a constexpr- generated sal_uString-compatible layout with a SAL_STRING_STATIC_FLAG refCount, conditionally for C++20 for now). For a configure-wise bare-bones build on Linux, size reported by `du -bs instdir` grew by 118792 bytes from 1155636636 to 1155755428. In most places just a u"..." string literal prefix had to be added. In some places char const a[] = "..."; variables have been changed to char16_t, and a few places required even further changes to code (which prompted the addition of include/o3tl/string_view.hxx helper function o3tl::equalsIgnoreAsciiCase and the additional OUString::createFromAscii overload). For all uses of macros expanding to string literals, the relevant uses have been rewritten as u"" MACRO instead of changing the macro definitions. It should be possible to change at least some of those macro definitions (and drop the u"" from their call sites) in follow-up commits. Change-Id: Iec4ef1a057d412d22443312d40c6a8a290dc6144 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101483 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-21Resolves: tdf#135518 Add English (Hong Kong) [en-HK] locale dataEike Rathke3-0/+36
Inherited from en-GB, zh-HK Change-Id: I966d19cfa2da26d3d882af35afe79a2f77eaffa8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101139 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2020-08-12fix i18n constructors and android scriptsNoel Grandin1-4/+4
after commit 155c056b1d4674d5ff73bbb5e1ad1dcd1e6aae36 i18npool: create instances with uno constructors this fixes two things (*) the names of some of the constructo functions were wrong (*) the native-code.py script needed updating Change-Id: I5f3cad78eb2f84cb78ba7fed9f98122858fc6b81 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100599 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-09tdf#135573 sw: add Székely rovás (Old Hungarian) numeralsLászló Németh1-1/+7
Change-Id: Ic309fc9b07186ce0b86ca54028d62e0fafd104fc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99950 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2020-08-09i18npool: create instances with uno constructorsNoel Grandin5-97/+87
and rename some classes to match their UNO implementation name. See tdf#74608 for motivation. Change-Id: I16aa64781d30a500f234029da6f6b00a645c46bb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100133 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-03tdf#133747 add missing character to make the sort feature work correctlyTomoyuki Kubota3-4176/+4176
Change-Id: Icea2dac6e4ef6493c2a7fe5f7def0f1708caf6d9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95684 Tested-by: Jenkins Reviewed-by: Tomoyuki Kubota <himajin100000@gmail.com> Reviewed-by: Eike Rathke <erack@redhat.com>
2020-07-29expand out macroNoel Grandin1-11/+15
Change-Id: I607e1defbd657546bfc017d16d0edfcf0dc2c028 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99721 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-07-29i18npool: create instances with uno constructorsNoel Grandin5-259/+220
See tdf#74608 for motivation. Change-Id: I814512ccc546bd015558a8122f0d2e3803437e38 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99722 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-07-29tdf#130154: update locale data for Estonian [et-EE] - follow-upMihkel Tõnnov1-16/+16
Follow-up for 4804d969bacd25ad586b3bf70d3dc8c27adb48ef: * change abbreviations to omit trailing periods, as officially preferred * add quotes around literal characters in date formats (so those formats wouldn't be mistakenly detected as "user-defined") * revert sorting of a few date formats for backwards compatibility's sake: - when opening files created in 7.0, previous versions shouldn't add ". a" anymore to formats that aren't supposed to have it Change-Id: I666273aa32e7ca363aa929b8a1fd83bf46533f6f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99264 Tested-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com> Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2020-07-23tdf#132082 Fix a crash in LOKit (Japanese-only)Andras Timar1-0/+5
Change-Id: I09c8d3a129c0d1d2fab561add0447869156b193f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96693 Tested-by: Andras Timar <andras.timar@collabora.com> Reviewed-by: Andras Timar <andras.timar@collabora.com>
2020-07-21i18npool: don't break line at slash '/'Michael Stahl1-1/+4
If sw text formatting gets the result of the special-case code added to the "word boundary break" condition, it may call again the next time with the preceding index, and fall into the "Line boundary break" condition, which hence also needs to special case '/'. (regression from ICU 60, 9206a08ada00e8762c4a634f242bd566028964bb) Change-Id: I2aaefbc7b25af157e0a6ef15fabaa71bff1e8d9a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99104 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-07-21loplugin:constantparamNoel Grandin1-5/+3
Change-Id: Id5144e95ac0120b3125258cdde46e4f7f6e1690b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99109 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-07-14i18npool/i18nsearch: create instances with uno constructorsNoel Grandin2-62/+9
See tdf#74608 for motivation. Change-Id: I5f8113393120fdad192f7347109a2186db141acb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98708 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-07-13tdf#134755 Update locale data for Kazakh [kk-KZ]Baurzhan Muftakhidinov1-16/+23
Change-Id: I47e920a98833f71bd5c8db0a0590a4f8cdcb83b5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98465 Tested-by: Jenkins Reviewed-by: Eike Rathke <erack@redhat.com>
2020-07-10replace usage of blacklist with excludelist for IWYUThorsten Behrens1-1/+1
Background and motivation: https://tools.ietf.org/html/draft-knodel-terminology-02 Change-Id: I2f22d455d2a936a85750eaab1fda215ebb6d9d48 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98182 Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2020-07-03only loop over props onceNoel Grandin1-20/+11
Change-Id: If41314c90397199c14c91fe65ed41243ac385dae Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97827 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-07-01Upcoming improved loplugin:staticanonymous -> redundantstatic: i18npoolStephan Bergmann24-119/+119
Change-Id: I8b93f7610103f4bd8e86e2d9f57929922b6dc92c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97568 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-06-14Replace ERROR macro and trace exception (i18npool/calendarImpl)Julien Nabet1-32/+30
Change-Id: Ie06a19b902e4dc12914fe0f2328a5abafa85368e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96208 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-06-12tdf#133898: get a context in default ctr (i18npool/calendarImpl)Julien Nabet2-1/+8
See bt here: https://bugs.documentfoundation.org/attachment.cgi?id=161882 Change-Id: If5a6c5e2b52af9ef97af9522296aaa58352cfa69 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96161 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-06-04Upcoming loplugin:elidestringvar: i18npoolStephan Bergmann3-11/+4
Change-Id: I5644ca7f2ef1b251ce1c262d3001ca48f2ed9edd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95482 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-05-31tdf#115382 AutoCorrect: fix Hungarian apostrophe usageLászló Németh1-2/+2
Single Quotes AutoCorrect, i.e. pressing Ctrl + ' will insert typographic apostrophes (third level Hungarian quoation marks) instead of » and «, like MSO does. This reverts commit 0d0c13bfbdff85a18433aee6e94558689f0cb722 (tdf#115382 Hungarian autocorrect: help apostrophe usage), too. See also commit b9910e87de4eea1cb3684bb7af8e58d681cbe809 (Resolves: tdf#116062 revert [fr-CH] to use previous single quote characters) Change-Id: I9ff5cb9a55699c253b6a57589186caa7caa170a8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95210 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-05-29loplugin:simplifybool in hwpfilter..lotuswordproNoel Grandin1-1/+1
Change-Id: Iedfd492c963eb89fe75fdd73cae630e7e1dae119 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95100 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-05-29pack a few more classesNoel Grandin2-2/+2
Change-Id: Ia7870d1d0d91de213727116ccda5b41913223866 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95097 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-05-21use for-range on Sequence in i18npool..sdNoel Grandin1-4/+3
Change-Id: I19eba57bc6058c317473d0746f06699a09ba2830 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94608 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-05-19tdf#130154: update locale data for Estonian [et-EE]Mihkel Tõnnov1-39/+87
* fix MinimalDaysInFirstWeek (supposed to be 4, not 1) * fix FollowPageWord ("jj." = "ja järgmine/järgmised", not "pp.") * fix Era DefaultAbbrvName & DefaultFullName to official spellings * add DefaultNarrowName for months (using Roman numerals) * translate TimeAM, TimePM - not commonly used, but abbreviations exist * changes to date formats: - add some that are used, but were missing - remove those that aren't commonly used or which are ungrammatical - switch to more sensible defaults - minor re-sorting into more logical order Change-Id: I2cf585febe7f100b2b63a94a3fd957a381adc131 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94256 Tested-by: Jenkins Reviewed-by: Eike Rathke <erack@redhat.com>
2020-05-15Change [zh-CN] keyword 'General' to '常规', tdf#88233Eike Rathke1-1/+1
Change-Id: I2f822a839724c7b4c2129d7f1bd1cce025b9289c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94254 Tested-by: Jenkins Reviewed-by: Eike Rathke <erack@redhat.com>
2020-05-10new loplugin:simplifypointertoboolNoel Grandin1-1/+1
Change-Id: Iff68e8f379614a6ab6a6e0d1bad18e70bc76d76a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91907 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-05-09compact namespace in i18npool..ooxNoel Grandin1-3/+1
Change-Id: I1de87468b56b86a1eeee09a612551ab119a1be8b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93857 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-05-07ICU requires that a collator charset data array is four-byte-alignedTor Lillqvist1-1/+1
See workdir/UnpackedTarball/icu/source/common/utrie2.cpp, the U_POINTER_MASK_LSB() check: if( length<=0 || (U_POINTER_MASK_LSB(data, 3)!=0) || valueBits<0 || UTRIE2_COUNT_VALUE_BITS<=valueBits ) { *pErrorCode=U_ILLEGAL_ARGUMENT_ERROR; return 0; } Apparently the data pointer there is always a multiple of four bytes from the start of the data array that the gencoll_rule code generates. Change-Id: I9b98b01b49b5800e1db8b077a4221b82d59510bf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93507 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93603 Tested-by: Jenkins Reviewed-by: Andras Timar <andras.timar@collabora.com>
2020-05-06Throw exceptions with useful messagesTor Lillqvist1-4/+22
Change-Id: Ic8e09d31db97c0cf2e1aaf006c96481d12deb2d8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93506 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93592 Tested-by: Jenkins
2020-04-27tdf#42982: Improve UNO API error reportingIan Barkley-Yeung1-3/+7
Improve error repoting in BreakIteratorImpl Change-Id: I0be64a758ed81b7a720c8b26af14de6b51cc5dbc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92955 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-04-20fix regressionNoel Grandin1-8/+8
from commit c5424e19338a3edaec3f0459c8ac5d53ca92d9fe loplugin:useuniqueptr in i18npool which would have resulted in the block at line 245 inside #if (U_ICU_VERSION_MAJOR_NUM < 58) never doing anything spotted while doing improvements to my make_shared plugin Change-Id: I79c664c7e4a051f3c764cb49d99870b51b19ce55 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92567 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-04-15loplugin:buriedassign in f,h,i*Noel Grandin2-16/+55
Change-Id: Iac753e528e13cb2565832a484e87f88061bbc91e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92239 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-04-08loplugin:flatten in i18npoolNoel Grandin5-71/+75
and workaround a clang crash Change-Id: Ida94c8abb4b2e997d38a7f430e59f73aadf8fcc8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91844 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-04-08fix Korean Hangul Syllable Character order tdf#130067DaeHyun Sung1-236/+1118
i18npool/source/collator/data/ko_charset.txt Korean Hangul syllables ordering is wrong. Some hangul syllables are dissapeared on the text file. Hangul Syllable ordering is already specified on Unicode Code chart. Ref. Hangul Syllables Range: AC00–D7AF https://unicode.org/charts/PDF/UAC00.pdf That commit applies only Hangul Syllables range. Korean Hanja[한자/漢字] range will require investigation. hanja[한자/漢字] is korean name for chinese character. Change-Id: I31e5cbf04294ee3bd6bff3277f9fe1328530ac3a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87018 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2020-04-02Resolves: tdf#131829 [vi-VN] set currency VND decimals to 0Eike Rathke1-5/+5
Change-Id: I865d6b3dcb7f3bff037a4015aa98db2fa2578672 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91593 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2020-03-31Translate German variable namesJohnny_M1-9/+9
Ende -> End Change-Id: I47faa58be14d9e608a4fad61279026d676c185c4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91207 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2020-03-25tdf#131153 Correct LongDateDaySeparator for fr_CH and it_CHJean-Louis Fuchs2-8/+8
According to localeplanet [1] [2], in comparison to other software and people living it these areas, the LongDateDaySeparator '.' for fr_CH and it_CH in LibreOffice is not correct. It should be omitted. [1] http://www.localeplanet.com/icu/it-CH/index.html [2] http://www.localeplanet.com/icu/fr-CH/index.html This means for the FormatElement index 22, 23, 24, 25, 26 should be the same in fr_CH/fr_FR and it_CH/it_IT. Change-Id: Ief4de0d8728c7a3bbcfac7f6200f37f2d2c647aa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90427 Tested-by: Jenkins Reviewed-by: Eike Rathke <erack@redhat.com>
2020-03-23sw: add pad-to-5 numberingMiklos Vajna2-0/+31
This is the last padded numbering type that is supported by Word but was not supported by Writer. Change-Id: Ica1a0843897c61a4b569105fd21e5bfe7b5012cb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90912 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-03-22tdf#131464: fix create an index of Writer in Japanese localeJulien Nabet1-2/+2
in i18npool/source/collator/collator_unicode.cxx, we got: 177 // replace algorithm name to implementation name. 178 if (rAlgorithm == "phonetic (alphanumeric first)") 179 aBuf.append("phonetic_alphanumeric_first"); 180 else if (rAlgorithm == "phonetic (alphanumeric last)") 181 aBuf.append("phonetic_alphanumeric_last"); 182 else 183 aBuf.append(rAlgorithm); So don't add extra ja_ before "phonetic..." Also we already add "ja" in buffer with line: 158 aBuf.append("get_").append(rLocale.Language).append("_"); so right functions from ICU will be retrieved Change-Id: I163c3ca4bb4dcfa1e5d29313190c5ba3e6396c4f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90877 Tested-by: Jenkins Reviewed-by: Eike Rathke <erack@redhat.com>
2020-03-20sw pad-to-4 numbering: add ODF filterMiklos Vajna1-0/+1
This makes the UI work as well. Change-Id: I4e94b85097cc359b257b07ba7517edfab3011093 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90827 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-28 09:56:28 +0000