summaryrefslogtreecommitdiff
path: root/i18npool
AgeCommit message (Collapse)AuthorFilesLines
2021-10-05drop 'using namespace std' in h* i* j*Julien Nabet1-4/+3
Change-Id: I3c28651779f17e1a410505ffaa863b4773037ccf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123119 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-10-03A more lightweight O[U]StringConcatenationStephan Bergmann2-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>
2021-10-01loplugin:constmethodNoel Grandin11-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>
2021-09-30Resolves: tdf#144697 Format out-of-bounds date(+time) as #FMT errorEike Rathke1-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
2021-09-18remove some allocationsNoel Grandin3-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>
2021-09-18cid#1491946 and cid#1491949 deference before null checkNoel Grandin4-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>
2021-09-17Fix calculation of alloca'ed memory sizeStephan Bergmann1-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
2021-09-16expand out unnecessary macroNoel Grandin2-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>
2021-09-16speedup Transliteration_body::transliterateImplNoel Grandin1-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>
2021-09-16speedup CharacterClassificationImpl::toUpperNoel Grandin22-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>
2021-09-06clang-tidy:clang-analyzer-optin.performance.PaddingNoel Grandin1-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>
2021-09-01clang-tidy:readability-redundant-member-initNoel Grandin2-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>
2021-08-26tdf#144089: Revert "tdf#137737 i18n search: don't expand start/end with ↵Xisco Fauli1-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>
2021-08-25tdf#137737 i18n search: don't expand start/end with regex ^ or $Justin Luth1-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>
2021-08-19tdf#143526 add Korean Numbering test case & fix Hanja number codepointDaeHyun Sung2-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>
2021-08-11no need to allocate the lookupTableItem separatelyNoel Grandin6-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>
2021-08-03Consolidate on C++17 std::scoped_lock instead of std::lock_guardNoel Grandin2-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>
2021-08-03Related: tdf#143664 Change {de-*} March "Mrz" to "Mär"Eike Rathke2-2/+2
Change-Id: Id4a4ebe432bf5badae96eadb723336648d2ce690 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119917 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2021-07-31tdf#143295 fix DateAcceptancePattern in KoreanDaeHyun Sung1-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
2021-07-29Make duplicate generated numbering identifiers unique, tdf#143526 follow-upEike Rathke2-4/+17
Change-Id: I28366c4e868e97b70e016b056b73b88b4cc8b812 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119677 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2021-07-29Add NumberingIdentifier unit test, tdf#143526 relatedEike Rathke1-0/+61
Change-Id: I9d4df6f63dc9ebc90e99fecce14b3551c74f7f1a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119675 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2021-07-29tdf#143526 fix and add Korean numberingDaeHyun Sung1-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>
2021-07-23do not use "using namespace std" in headersCollabora2-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>
2021-07-18osl::Mutex->std::mutex in NativeNumberSupplierNoel Grandin1-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>
2021-07-18osl::Mutex->std::mutex in NumberFormatCodeMapperNoel Grandin2-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>
2021-07-05Resolves tdf#137160 - Thin space before f./ff. in en_USHeiko Tietze1-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>
2021-07-05Fix Line break rule in KoreanDaeHyun Sung1-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>
2021-07-05Related: tdf#125035 Include day of week in formatindex="19" DATE_SYSTEM_LONGEike Rathke1-1/+1
Change-Id: I3cbbda7592fede575b766f0631c5f4b42a19e03e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118387 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2021-07-04tdf#143173: fix wrong French abbr for Alphabetical Index-Grouped entriesJulien Nabet1-2/+2
Change-Id: If478fc1127f957e05cdf7bc247881f0c59146896 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118366 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-07-03Related: tdf#125035 en_US formatindex="19" DATE_SYSTEM_LONG with D not DDEike Rathke1-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
2021-07-03Related: tdf#125035 Include day of week in formatindex="19" DATE_SYSTEM_LONGEike Rathke20-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
2021-06-28loplugin:indentation improve checks for brace alignmentNoel Grandin3-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>
2021-06-14We only support ICU version 4.6 or newer, so drop these checksMike Kaganski2-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>
2021-06-09dtd files are not xml files and shouldn't have xml headersCaolán McNamara1-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>
2021-06-09Simplify Sequences initializations (i*->p*)Julien Nabet4-55/+19
Change-Id: I6bf0eaa2233de2487d90a2f9ae7de263b4ddf1bd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116865 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-06-07Resolves: tdf#142216 Fix {hu-HU} AM/PM words, default time without leading 0Eike Rathke1-4/+4
Change-Id: Ief925b01a882bd59807b7e6e8c84b77b5ca3485f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116713 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2021-06-04Fix the <FollowPageWord> entries for BulgarianMIhail Balabanov1-2/+2
Change-Id: I349a5a1fc9a93225f6129bd26f0387a3681f08ef Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113860 Tested-by: Jenkins Reviewed-by: Eike Rathke <erack@redhat.com>
2021-05-25Don't ignore GCC warnings for static buildsJan-Marek Glogowski1-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>
2021-05-17don't leak ICU transliteratorNoel Grandin2-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>
2021-05-15Related: tdf#128314 Add NatNum12 modifier 'lower' attributeEike Rathke1-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
2021-05-14Improve loplugin:stringviewStephan Bergmann3-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>
2021-05-14Typos in commentsMike Kaganski1-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>
2021-05-06Add English (Denmark) {en-DK} locale dataEike Rathke3-0/+240
Using ',' comma decimal separator and '.' dot group separator. ISO 8601 date(+time) formats. Inheriting calendar from {en-GB} (week-1stweek=4 first_weekday=2). Currency DKK 'kr.' symbol. Secondary currency EUR '€' symbol. See also https://lh.2xlibre.net/locale/en_DK/ Change-Id: Idcf1e52af0ac20412efa42d3873ab1e34a2f1eaf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115177 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2021-05-06Change en_GB calendar StartDayOfWeek to Monday and MinimalDaysInFirstWeek to 4Eike Rathke1-1/+11
Inherit day, month and era names from en_US but with proper values. See https://lh.2xlibre.net/locale/en_GB/ - Week definition (week) - First day of week (first_weekday) or % LC_TIME=en_US locale -k LC_TIME week-ndays=7 week-1stday=19971130 week-1stweek=1 first_weekday=1 first_workday=2 % LC_TIME=en_GB locale -k LC_TIME week-ndays=7 week-1stday=19971130 week-1stweek=4 first_weekday=2 first_workday=2 This makes it necessary to adapt basic/qa/vba_tests/weekdayname.vb because basic/qa/cppunit/test_vba.cxx sets LANGUAGE_ENGLISH_UK Change-Id: I752bf0e59396f0cbd601beb596c07e77e4e4cfaf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115160 Tested-by: Jenkins Reviewed-by: Eike Rathke <erack@redhat.com>
2021-05-06Derive en_HK calendar from en_US instead of en_GBEike Rathke1-1/+1
Reason is that en_US start day of week is Sunday and en_GB is to be changed to Monday but en_HK is to be kept on Sunday. See also https://lh.2xlibre.net/locale/en_HK/ that does not override First day of week (first_weekday). Change-Id: I7f1b4059a23c8a6cdf6e30a3a6d18e2b911f4974 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115159 Tested-by: Jenkins Reviewed-by: Eike Rathke <erack@redhat.com>
2021-05-05Move en_KE to lcl_DATA_EN where it belongsEike Rathke3-5/+5
Comment en_IN and en_MY why they should / have to stay. Change-Id: I816741324bfc328ec4e0bf269ec27f65fe79f3f6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115154 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2021-04-27loplugin:moveoptNoel Grandin1-4/+2
An attempt that did not find anything convincing enough to finish it up and make it permanently active. So just leave it in /store for now. Change-Id: I1750e177655a4a510da100f880ba81bf762be277 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114742 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-04-27loplugin:stringadd convert chained append to +Noel Grandin1-2/+2
which can use the more efficient *StringConcat Also fix a crash in stringview plugin which started happening while I working on this. Change-Id: I91a5b9b7707d1594d27d80b73930f5afac8ae608 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114568 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-04-10Quote literals in {ja-JP} date and time format codesEike Rathke1-15/+15
Because when loading number formats from ODF literal text is enquoted that resulted in duplicated formats that differed only in quoted literals vs unquoted literals with identical functionality, but unnecessarily polluting the number formats list. Since commit 5d1042cbd25b22babaf8b30bc4edff6f70750b5e CommitDate: Sat Apr 10 03:49:37 2021 +0200 ODF load: use AAA/AAAA instead of NN/NNN(N) for implicit secondary calendar these predefined format codes now load actually identical. Change-Id: I02b5367ecd8ddab4419a56ba4d1c3ac4233142b5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113925 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2021-04-07Updated README.md files to represent current code / use Markdown formatHossein1-5/+10
Previously, all of the README files have been renamed to README.md and now, the contents of these files were changed to use Markdown format. Other than format inconsistency, some README.md files lacked information about modules, or were out of date. By using LibreOffice / OpenOffice wiki and other documentation websites, these files were updated. Now every README.md file has a title, and some description. The top-level README.md file is changed to add links to the modules. The result of processing the Markdown format README.md files can be seen at: https://docs.libreoffice.org/ Change-Id: Ic3b0c3c064a2498d6a435253b041df010cd7797a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113424 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-02 06:58:05 +0000