summaryrefslogtreecommitdiffstats
path: root/i18npool
Commit message (Collapse)AuthorAgeFilesLines
* Missing `static`Stephan Bergmann2021-10-251-1/+1
| | | | | | | | | | | | | | | | ...from aa2064c5c5f23f6f4b7bc44e12345b37f66995bc "Improve loplugin:stringliteralvar", similar to 8b32a3edad52f8ac5e5f0f49b4f4e80954c2fd25 "Fix stack-use-after-scope" (though this case doesn't appear to have caused any actual issues). (After manual inspection, there appear to be no further missing `static` at least in aa2064c5c5f23f6f4b7bc44e12345b37f66995bc "Improve loplugin:stringliteralvar".) Change-Id: I2b3d0d8d2af1d65f0c5bef8a858107020a620974 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124137 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
* loplugin:flattenNoel Grandin2021-10-211-11/+12
| | | | | | | Change-Id: I3b4226a9d089ec9aedab95d96e50a068f57a76c7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123991 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
* Resolves: tdf#145173 Add English (Israel) {en-IL} locale dataEike Rathke2021-10-193-1/+46
| | | | | | | | | | | Mainly inherit from he_IL but the calendars from en_US that also already define the Jewish calendar items with English names. Jewish calendar date formats also from en_US LC_FORMAT_1. Change-Id: I0907898190adcd46687ca1308fe6785fd9c9c4ad Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123845 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
* Related: tdf#145173 Sort he_IL by formatindex and split NatNum to LC_FORMAT_1Eike Rathke2021-10-191-81/+95
| | | | | | | | | | | ... keeping all LC_FORMAT as non-NatNum elements and separating all NatNum into LC_FORMAT_1, to be able to separately inherit LC_FORMAT. Change-Id: I42387432205862ca6416e6a3d020a923408c7b8c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123844 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
* Related: tdf#145173 Handle two independent ref=... for LC_FORMAT...Eike Rathke2021-10-191-1/+2
| | | | | | | Change-Id: I6313d9e573e653c9a97171ca8c2f6176d7ad6a3f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123843 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
* Remove non-const Sequence::begin()/end() in internal codeMike Kaganski2021-10-1510-17/+17
| | | | | | | | | | | | | | | | | | ... to avoid hidden cost of multiple COW checks, because they call getArray() internally. This obsoletes [loplugin:sequenceloop]. Also rename toNonConstRange to asNonConstRange, to reflect that the result is a view of the sequence, not an independent object. TODO: also drop non-const operator[], but introduce operator[] in SequenceRange. Change-Id: Idd5fd7a3400fe65274d2a6343025e2ef8911635d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123518 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
* [API CHANGE] Fix all bad UNOIDL identifiers across offapiStephan Bergmann2021-10-141-18/+18
| | | | | | | | | | | | | | | | | | | | | | | | | Identifiers containing underscores must start with an uppercase letter. (So that the UNO implementation can use identifiers containing underscores and starting with a lowercase letter for internal purposes, see e.g. the static_type member functions in the C++ *.hdl files. idlc checks that with the -cid option, while unoidl-write silently allows bad identifiers for now, see the TODO in unoidl/source/sourceprovider-scanner.l, which can be dropped after this change.) All of the affected identifiers were present since early OOo times, but none of them appear to be used much, at least not across LO itself, so there is hope that we can get away with these incompatible changes. (For the constant group members, we could roll this out in two steps, introducing the new members alongside the old ones and deprecating the old ones in a first step, then removing the old, deprecated ones in a second step, so that third-party code would have more time to adapt. But that would not work for the enum members and interface methods, so just do all of this in one breaking step.) udkapi happened to not contain any bad identifiers. Change-Id: If2d4c16563606f9efb48b937c76af54746377428 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121725 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
* Avoid COW overhead using css::uno::SequenceMike Kaganski2021-10-148-54/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The scenarios are: 1. Calling sequence's begin() and end() in pairs to pass to algorithms (both calls use getArray(), which does the COW checks) 2. In addition to #1, calling end() again when checking result of find algorithms, and/or begin() to calculate result's distance 3. Using non-const sequences in range-based for loops, which internally do #1 4. Assigning sequence to another sequence variable, and then modifying one of them In many cases, the sequences could be made const, or treated as const for the purposes of the algorithms (using std::as_const, std::cbegin, and std::cend). Where algorithm modifies the sequence, it was changed to only call getArray() once. For that, css::uno::toNonConstRange was introduced, which returns a struct (sublclass of std::pair) with two iterators [begin, end], that are calculated using one call to begin() and one call to getLength(). To handle #4, css::uno::Sequence::swap was introduced, that swaps the internal pointer to uno_Sequence. So when a local Sequence variable should be assigned to another variable, and the latter will be modified further, it's now possible to use swap instead, so the two sequences are kept independent. The modified places were found by temporarily removing non-const end(). Change-Id: I8fe2787f200eecb70744e8b77fbdf7a49653f628 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123542 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
* drop 'using namespace std' in h* i* j*Julien Nabet2021-10-051-4/+3
| | | | | | | Change-Id: I3c28651779f17e1a410505ffaa863b4773037ccf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123119 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
* A more lightweight O[U]StringConcatenationStephan Bergmann2021-10-032-3/+3
| | | | | | | | | | | | | | | | | | | | | | | ...compared to a full-blown O[U]String, for temporary objects holding an O[U]StringConcat result that can then be used as a std::[u16]string_view. It's instructive to see how some invocations of operator ==, operator !=, and O[U]StringBuffer::insert with an O[U]StringConcat argument required implicit materialization of an O[U]String temporary, and how that expensive operation has now been made explicit with the explicit O[U]StringConcatenation ctor. (The additional operator == and operator != overloads are necessary because the overloads taking two std::[u16]string_view parameters wouldn't even be found here with ADL. And the OUString-related ones would cause ambiguities in at least sal/qa/rtl/strings/test_oustring_stringliterals.cxx built with RTL_STRING_UNITTEST, so have simply been disabled for that special test-code case.) Change-Id: Id29799fa8da21a09ff9794cbc7cc9b366e6803b8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122890 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
* loplugin:constmethodNoel Grandin2021-10-0111-18/+18
| | | | | | | Change-Id: I3ed657c5c5e6840e38e3c8505505b4b372125df0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122910 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
* Resolves: tdf#144697 Format out-of-bounds date(+time) as #FMT errorEike Rathke2021-09-301-17/+36
| | | | | | | | | | | | | | | | i.e. < -32768-01-01 or > 32767-12-31 They couldn't be input or stored as proleptic Gregorian in file formats anyway. Additionally in i18npool handle the absolute year values casting conversion int32 <-> int16 where era 0 BCE year 32768 is fielded as -32768 but still is a valid year for our proleptic Gregorian, so it isn't displayed as --32768. Change-Id: Ifdd482f07e04c2a4296fd0556bbef7f1d3e15676 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122835 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
* remove some allocationsNoel Grandin2021-09-183-8/+10
| | | | | | | | | where we could be calling static methods Change-Id: I9efef083e6ff307441fb36c19eac9134d960edec Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122300 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
* cid#1491946 and cid#1491949 deference before null checkNoel Grandin2021-09-184-64/+62
| | | | | | | | | | | | | after commit c7551e8a46e2f9f8142aa7921a0494221ae096e8 Author: Noel Grandin <noel.grandin@collabora.co.uk> Date: Thu Sep 16 10:36:48 2021 +0200 speedup CharacterClassificationImpl::toUpper Change-Id: If09857f89a4fa7de56831ea16d0b3ec8c50cfaf8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122295 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
* Fix calculation of alloca'ed memory sizeStephan Bergmann2021-09-171-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | ...after 16d645e5b8f11b4ddb49a2b58bde388b28960abc "speedup Transliteration_body::transliterateImpl", which caused dynamic-stack-buffer-overflow (<https://ci.libreoffice.org/job/lo_ubsan/2137/), > ==4003==ERROR: AddressSanitizer: dynamic-stack-buffer-overflow on address 0x7fffe890f7d2 at pc 0x0000004b1c2d bp 0x7fffe890f490 sp 0x7fffe890ec40 > WRITE of size 2 at 0x7fffe890f7d2 thread T0 > #0 0x4b1c2c in __asan_memmove /home/tdf/lode/packages/llvm-llvmorg-9.0.1.src/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cc:30 > #1 0x2b8b4222ef65 in char16_t* std::__copy_move<false, true, std::random_access_iterator_tag>::__copy_m<char16_t>(char16_t const*, char16_t const*, char16_t*) /home/tdf/lode/opt_private/gcc-7.3.0/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../include/c++/7.3.0/bits/stl_algobase.h:368:6 > #2 0x2b8b4222eec0 in char16_t* std::__copy_move_a<false, char16_t const*, char16_t*>(char16_t const*, char16_t const*, char16_t*) /home/tdf/lode/opt_private/gcc-7.3.0/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../include/c++/7.3.0/bits/stl_algobase.h:385:14 > #3 0x2b8b4222d9be in char16_t* std::__copy_move_a2<false, char16_t const*, char16_t*>(char16_t const*, char16_t const*, char16_t*) /home/tdf/lode/opt_private/gcc-7.3.0/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../include/c++/7.3.0/bits/stl_algobase.h:422:18 > #4 0x2b8b4222d2be in char16_t* std::copy<char16_t const*, char16_t*>(char16_t const*, char16_t const*, char16_t*) /home/tdf/lode/opt_private/gcc-7.3.0/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../include/c++/7.3.0/bits/stl_algobase.h:454:15 > #5 0x2b8b4222cf43 in char16_t* std::__copy_n<char16_t const*, signed char, char16_t*>(char16_t const*, signed char, char16_t*, std::random_access_iterator_tag) /home/tdf/lode/opt_private/gcc-7.3.0/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../include/c++/7.3.0/bits/stl_algo.h:782:14 > #6 0x2b8b4222b495 in char16_t* std::copy_n<char16_t const*, signed char, char16_t*>(char16_t const*, signed char, char16_t*) /home/tdf/lode/opt_private/gcc-7.3.0/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../include/c++/7.3.0/bits/stl_algo.h:806:14 > #7 0x2b8b42225872 in i18npool::Transliteration_body::transliterateImpl(rtl::OUString const&, int, int, com::sun::star::uno::Sequence<int>*) /i18npool/source/transliteration/transliteration_body.cxx:145:13 > #8 0x2b8b42236f35 in i18npool::transliteration_commonclass::transliterateString2String(rtl::OUString const&, int, int) /i18npool/source/transliteration/transliteration_commonclass.cxx:109:12 > #9 0x2b8b41fbc740 in i18npool::cclass_Unicode::toUpper(rtl::OUString const&, int, int, com::sun::star::lang::Locale const&) /i18npool/source/characterclassification/cclass_unicode.cxx:67:19 > #10 0x2b8b41fbc7b2 in non-virtual thunk to i18npool::cclass_Unicode::toUpper(rtl::OUString const&, int, int, com::sun::star::lang::Locale const&) /i18npool/source/characterclassification/cclass_unicode.cxx > #11 0x2b8b41ff1335 in i18npool::CharacterClassificationImpl::toUpper(rtl::OUString const&, int, int, com::sun::star::lang::Locale const&) /i18npool/source/characterclassification/characterclassificationImpl.cxx:47:63 [...] Change-Id: I5273e234c8921f635e31c414cb0e427ee8b04a95 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122234 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Jenkins
* expand out unnecessary macroNoel Grandin2021-09-162-40/+36
| | | | | | | Change-Id: Id812b720413bfe9ea678910fc8d9d0a64dd32d92 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122195 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
* speedup Transliteration_body::transliterateImplNoel Grandin2021-09-161-2/+5
| | | | | | | | | | | use alloca in Transliteration_body::transliterateImpl to avoid over-allocating stack-space (which tends to unnecessarily flush some cache) Change-Id: I1843fdcb830a3e948a8bbd0a9c7eb143b21a804c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122184 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
* speedup CharacterClassificationImpl::toUpperNoel Grandin2021-09-1622-128/+128
| | | | | | | | | | | remove empty sequence creation in CharacterClassificationImpl::toUpper, rather pass a pointer, so it can be nullptr. Which results in a fair degree of cascading change. Change-Id: Ie56d49dc71480195c1807764b0d5124f0019f30b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122183 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
* clang-tidy:clang-analyzer-optin.performance.PaddingNoel Grandin2021-09-061-3/+5
| | | | | | | | | | noting that XMLTokenEnum was already being treated as being limited to 32-bits, we bitmask it together with namespaces Change-Id: Ic48f2a662452d1b8e022078d31a723d2ac65aef0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121707 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
* clang-tidy:readability-redundant-member-initNoel Grandin2021-09-012-3/+1
| | | | | | | Change-Id: I78339f1df1f0c55c7edaa552940b07d1ada3aeb5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121386 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
* tdf#144089: Revert "tdf#137737 i18n search: don't expand start/end with ↵Xisco Fauli2021-08-261-2/+2
| | | | | | | | | | | | | regex ^ or $" This reverts commit a511bffd67a9cebfdc878766581ac08c79d7ff51. Reason for revert: See https://gerrit.libreoffice.org/c/core/+/120981 Change-Id: If8a445448976a9963f76623d3d968b8d5e3d74dd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120990 Tested-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
* tdf#137737 i18n search: don't expand start/end with regex ^ or $Justin Luth2021-08-251-2/+2
| | | | | | | | | | | | | | | | | | | | If the regex starts with ^, that means that it matches only at the beginning of the content. So don't expand the beginning of the content or else it won't match anymore. Similarly, $ indicates matching at the end of the content. For the unit test I just randomly guessed at SearchItem.AlgorithmType, and it kinda worked. I love black boxes... I hope I remember what i learned about TransformParameters() which was parsed in sfx2/source/appl/appuno.cxx, splitting the "variable" into Item.PropName = PropValue. That is definite black magic. Change-Id: Ie1640821a7a430e78dbe72c57a92aeaa9b5272a3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120410 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org>
* tdf#143526 add Korean Numbering test case & fix Hanja number codepointDaeHyun Sung2021-08-192-2/+284
| | | | | | | | | | | | | | | | | | | | | add Korean Numbering test cases 1. koreanCounting 2. koreanLegal 3. koreanDigital 4. koreanDigital2 fix Korean Hanja number codepoint for Zero(0) Following MS Office's numFmt Strng example https://docs.microsoft.com/en-us/openspecs/office_standards/ms-docx/a1bb5809-e361-4e49-8e16-7f1a67da4121 Korean Hanja notation for Hanja is `零 U+96F6` on MS Word 2019 and that document. So, fix the Korean Hanja number code pointfor Zero(0) `零 U+96F6` Change-Id: I1a5b95640a93e7fbc3a0e724b154587877b198a0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120676 Tested-by: Jenkins Reviewed-by: Eike Rathke <erack@redhat.com>
* no need to allocate the lookupTableItem separatelyNoel Grandin2021-08-116-27/+27
| | | | | | | Change-Id: I43919a002df01c6329ee483bf69f04669cdce1f6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120293 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
* Consolidate on C++17 std::scoped_lock instead of std::lock_guardNoel Grandin2021-08-032-6/+6
| | | | | | | | | as in commit 9376f65a26240441bf9dd6ae1f69886dc9fa60fa Change-Id: I3ad9afd4d113582a214a4a4bc7eea55e38cd6ff9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119927 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
* Related: tdf#143664 Change {de-*} March "Mrz" to "Mär"Eike Rathke2021-08-032-2/+2
| | | | | | | Change-Id: Id4a4ebe432bf5badae96eadb723336648d2ce690 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119917 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
* tdf#143295 fix DateAcceptancePattern in KoreanDaeHyun Sung2021-07-311-0/+5
| | | | | | | | | | | In Korean, both "YYYY-MM-DD"(ISO8601) and "YYYY. MM. DD."Hangul orthography(한글맞춤법)" are public and usually use in Korean. So, I fixed DateAcceptancePattern elements in Korean on i18npool/source/localedata/data/ko_KR.xml Change-Id: Iae3dfc63f4c67f4e1a74df7686daf2c2187c0b35 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118708 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
* Make duplicate generated numbering identifiers unique, tdf#143526 follow-upEike Rathke2021-07-292-4/+17
| | | | | | | Change-Id: I28366c4e868e97b70e016b056b73b88b4cc8b812 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119677 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
* Add NumberingIdentifier unit test, tdf#143526 relatedEike Rathke2021-07-291-0/+61
| | | | | | | Change-Id: I9d4df6f63dc9ebc90e99fecce14b3551c74f7f1a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119675 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
* tdf#143526 fix and add Korean numberingDaeHyun Sung2021-07-291-0/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | fix Korean NumberFormat, compare with MS Word change mapping of style::NumberingType::NUMBER_HANGUL_KO, from "koreanLegal" to "koreanCounting" "koreanDigital" add new reserved words "일, 일영, 일영영, etc" - style::NumberingType::NUMBER_DIGITAL_KO "koreanLegal" is new reserved words "하나, 둘, 셋, 넷, 다섯, 여섯, 일곱, 여덟, 아홉, 열" - style::NumberingType::NUMBER_LEGAL_KO "koreanDigital2" is new reserved words "一, 一零, 一零零, etc" - style::NumberingType::NUMBER_DIGITAL2_KO Reference: 1: "[MS-OE376]: Office Implementation Information for ECMA-376 Standards Support" https://docs.microsoft.com/en-us/openspecs/office_standards/ms-oe376/a5deef83-bb01-410f-bde0-9c35abe4ca52 2.1.350 Part 4 Section 2.13.5.30, numberingChange (Previous Paragraph Numbering Properties) 2: "[MS-DOCX]: Word Extensions to the Office Open XML (.docx) File Format" shows example of not only Korean Numbering also others Numbering examples. https://docs.microsoft.com/en-us/openspecs/office_standards/ms-docx/b839fe1f-e1ca-4fa6-8c26-5954d0abbccd 2.4 numFmt Extensions https://docs.microsoft.com/en-us/openspecs/office_standards/ms-docx/a1bb5809-e361-4e49-8e16-7f1a67da4121 Change-Id: I535b2aa3cf4111d86b9b7b788afe4aa64e8e4545 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119518 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
* do not use "using namespace std" in headersCollabora2021-07-232-1/+1
| | | | | | | | | | It's a bad style, doing that in headers can affect many source files (especially with PCH used). Change-Id: Ic9091a1d018e74606c9fa95df71a55faaa93d4ac Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119011 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
* osl::Mutex->std::mutex in NativeNumberSupplierNoel Grandin2021-07-181-5/+7
| | | | | | | Change-Id: I5430636438723f99b584dd95be9d7cb5264a5af9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119131 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
* osl::Mutex->std::mutex in NumberFormatCodeMapperNoel Grandin2021-07-182-5/+6
| | | | | | | Change-Id: I79d95ca1e5aa29d0a416d8870430062fd2b9936a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119130 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
* Resolves tdf#137160 - Thin space before f./ff. in en_USHeiko Tietze2021-07-051-2/+2
| | | | | | | Change-Id: I3a2f2206d9784de2da6af8ea2b882e1ebe6205e0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118439 Tested-by: Jenkins Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
* Fix Line break rule in KoreanDaeHyun Sung2021-07-051-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | I found the bug, Line break rule in Korea don't work using `" -U+0022: Quotation Mark` & `' - U+0027: Apostrophe` So I fixed the bug in xml file. `&apos;` to `' - U+0027: Apostrophe` `&quot;` to `" - U+0022: Quotation Mark` Because, `'` and `"` are still displayed in several other line break rules. such as, zh_CN.xml and zh_TW.xml, etc. Reference1: HWP Guide - 금칙문자(Forbidden Characters) http://help.hancom.com/hoffice/webhelp/9.0/ko_kr/hshow/tool/forbid.htm Reference2: OOXML ISO/IEC 29500–1:2016(E) Korean * Cannot start a line: !%),.:;?]}¢°'"′″℃〉》」』】〕！％），．：；？］｝￠ (Unicode character values: U+0021, U+0025, U+0029, U+002C, U+002E, U+003A, U+003B, U+003F, U+005D, U+007D, U+00A2, U+00B0, U+2019, U+201D, U+2032, U+2033, U+2103, U+3009, U+300B, U+300D, U+300F, U+3011, U+3015, U+FF01, U+FF05, U+FF09, U+FF0C, U+FF0E, U+FF1A, U+FF1B, U+FF1F, U+FF3D, U+FF5D and U+FFE0, respectively) * Cannot end a line: $([\{£¥'"〈《「『【〔＄（［｛￡￥￦ (Unicode character values: U+0024, U+0028, U+005B, U+005C, U+007B, U+00A3, U+00A5, U+2018, U+201C, U+3008, U+300A, U+300C, U+300E, U+3010, U+3014, U+FF04, U+FF08, U+FF3B, U+FF5B, U+FFE1, U+FFE5, and U+FFE6, respectively) Change-Id: I07f6afc60d0a83508a8ba971f31d2ca66846cd23 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118027 Tested-by: Eike Rathke <erack@redhat.com> Reviewed-by: Eike Rathke <erack@redhat.com>
* Related: tdf#125035 Include day of week in formatindex="19" DATE_SYSTEM_LONGEike Rathke2021-07-051-1/+1
| | | | | | | Change-Id: I3cbbda7592fede575b766f0631c5f4b42a19e03e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118387 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
* tdf#143173: fix wrong French abbr for Alphabetical Index-Grouped entriesJulien Nabet2021-07-041-2/+2
| | | | | | | Change-Id: If478fc1127f957e05cdf7bc247881f0c59146896 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118366 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
* Related: tdf#125035 en_US formatindex="19" DATE_SYSTEM_LONG with D not DDEike Rathke2021-07-031-1/+1
| | | | | | | | | | | | | | | | | | | | Otherwise CppunitTest_sw_odfimport testDateFormFormats fails with - Expected: Wednesday, March 4, 2020 - Actual : Wednesday, March 04, 2020 if DateFormatter uses number formatter. This is also what https://www.localeplanet.com/icu/en-US/index.html lists for Date.0 and formatindex="30" has as well. This makes adapting CppunitTest_svl_qa_cppunit testNumberFormat necessary. Change-Id: I1c8cfd954f34f742b0397b8f922d22eb11ae19f0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118361 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
* Related: tdf#125035 Include day of week in formatindex="19" DATE_SYSTEM_LONGEike Rathke2021-07-0320-20/+20
| | | | | | | | | | | | | | | | | | | | Used programmatically with number formatter's NF_DATE_SYSTEM_LONG but quite some locales were lacking the day of week; maybe legacy because duplicated formats sometimes were avoided, which nowadays are suppressed in the number format dialog. Made the format code a copy of formatindex="30" explicit DATE_SYS_NNNNDMMMMYYYY. Didn't know what to do about lt_LT so kept that as is. This made it necessary to adapt a dreaded UITest_writer_tests5 test that checks for listbox content, test_date_field_with_custom_format, which depends on actual locale data. See comment there. Change-Id: Ifc26a4a5be6bed3fb8d9cedc1afcba1225751635 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118335 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
* loplugin:indentation improve checks for brace alignmentNoel Grandin2021-06-283-128/+141
| | | | | | | Change-Id: I333100fda7e181f68f36b03279b3fbb8cb768310 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117615 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
* We only support ICU version 4.6 or newer, so drop these checksMike Kaganski2021-06-142-10/+0
| | | | | | | | | The minimal ICU version check is in configure.ac. Change-Id: Ib6480cd3290dabb45d87c6dcbcc9b5513d172e21 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117119 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
* dtd files are not xml files and shouldn't have xml headersCaolán McNamara2021-06-091-1/+0
| | | | | | | | | | so rpminspect is correct in complaining that they are not valid xml on inspecting files claiming to be xml Change-Id: I70379989326c2ea63e6a54b3658ebea4684fa5df Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116887 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
* Simplify Sequences initializations (i*->p*)Julien Nabet2021-06-094-55/+19
| | | | | | | Change-Id: I6bf0eaa2233de2487d90a2f9ae7de263b4ddf1bd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116865 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
* Resolves: tdf#142216 Fix {hu-HU} AM/PM words, default time without leading 0Eike Rathke2021-06-071-4/+4
| | | | | | | Change-Id: Ief925b01a882bd59807b7e6e8c84b77b5ca3485f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116713 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
* Fix the <FollowPageWord> entries for BulgarianMIhail Balabanov2021-06-041-2/+2
| | | | | | | Change-Id: I349a5a1fc9a93225f6129bd26f0387a3681f08ef Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113860 Tested-by: Jenkins Reviewed-by: Eike Rathke <erack@redhat.com>
* Don't ignore GCC warnings for static buildsJan-Marek Glogowski2021-05-251-13/+10
| | | | | | | | | | Instead simply (and correctly) test the function pointers in the static build case. Change-Id: I01b3397f40671464b1d2cb472447d8530b996d21 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116117 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
* don't leak ICU transliteratorNoel Grandin2021-05-172-3/+4
| | | | | | | Change-Id: Ib2c09c6c63b94d078ddde15585caa59710953bba Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115702 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
* Related: tdf#128314 Add NatNum12 modifier 'lower' attributeEike Rathke2021-05-151-1/+5
| | | | | | | | | Similar to capitalize, upper and title. Change-Id: I5933362e69ebbc3cf31de4258aceec5677b76653 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115640 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
* Improve loplugin:stringviewStephan Bergmann2021-05-143-4/+6
| | | | | | | | | | | | | | | | | Issue the "instead of O[U]String, pass [u16]string_view" diagnostic also for operator call arguments. (The "rather than copy, pass subView()" diagnostic is already part of handleSubExprThatCouldBeView, so no need to repeat it explicitly for operator call arguments.) (And many call sites don't even require an explicit [u16]string_view, esp. with the recent ad48b2b02f83eed41fb1eb8d16de7e804156fcf1 "Optimized OString operator += overloads". Just some test code in sal/qa/ that explicitly tests the O[U]String functionality had to be excluded.) Change-Id: I8d55ba5a7fa16a563f5ffe43d245125c88c793bc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115589 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
* Typos in commentsMike Kaganski2021-05-141-1/+1
| | | | | | | Change-Id: I6d421f007f6a4b1550e0c8c907feea2472216502 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115517 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
generated by cgit (git 2.34.1) at 2024-06-24 07:41:51 +0000