summaryrefslogtreecommitdiff
path: root/l10ntools
AgeCommit message (Collapse)Author
2021-01-27pocheck: don't require reference for stock labelsChristian Lohmaier
See d5d905b480c2a9b1db982f2867e87b5c230d1ab9 and related commits for the rationale on why those are not extracted like other strings. Change-Id: I2a339747626e0fb314cac7f57bccb2b91853249c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109916 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2021-01-15prep to replace stock button labelsCaolán McNamara
a) as per https://developer.gnome.org/gtk3/stable/gtk3-Stock-Items.html use-stock=gtk-ok is deprecated and plain "OK", "Cancel" are indicated instead. b) to avoid adding thousands of extra labels to translate we'll convert use-stock buttons to use the translatable strings, but give them all the same "stock" translation context. Our translation rules don't like duplicates in the output .po's so strip "stock" contents from the translation collection rules in uiex and add a single set per .po in l10ntools/source/localize.cxx c) a script to rewrite the .uis to the new rules the previously use-stock labels won't appear translated until there has been a round trip of extraction, translations and import of translations Change-Id: Ibe4d0d27f2abbf5aa3df9c63af1561cd01d9fddd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108812 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-29loplugin:stringviewparam: operator +Stephan Bergmann
Change-Id: I044dd21b63d7eb03224675584fa143009c6b6008 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108418 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-27Simplify loplugin:stringviewparam comparison operator handlingStephan Bergmann
In practice, it works fine to look at all of them, regardless of actual argument types. Change-Id: Ifc49cbcd6003c8837c1b3f81d432c59fb0657bf1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108366 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-11Adapt the remaining OUString functions to std string_viewStephan Bergmann
...for LIBO_INTERNAL_ONLY. These had been missed by 1b43cceaea2084a0489db68cd0113508f34b6643 "Make many OUString functions take std::u16string_view parameters" because they did not match the multi-overload pattern that was addressed there, but they nevertheless benefit from being changed just as well (witness e.g. the various resulting changes from copy() to subView()). This showed a conversion from OStringChar to std::string_view to be missing (while the corresponding conversion form OUStringChar to std::u16string_view was already present). The improvement to loplugin:stringadd became necessary to fix > [CPT] compilerplugins/clang/test/stringadd.cxx > error: 'error' diagnostics expected but not seen: > File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 43 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:42): simplify by merging with the preceding assignment [loplugin:stringadd] > File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 61 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:60): simplify by merging with the preceding assignment [loplugin:stringadd] > 2 errors generated. Change-Id: Ie40de0616a66e60e289c1af0ca60aed6f9ecc279 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107602 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-09Apparently, Windows doesn't have the concept of a set but empty env varStephan Bergmann
...so in an (implicitly) --disable-release-build build (where config_host.mk contains a export ENABLE_RELEASE_BUILD= line), getenv("ENABLE_RELEASE_BUILD") returns null, and after a5484e496dcee9b110ef696101576a14b7a5a20e "Assert that certain env vars are set in these build-time tools" e.g. `make CustomTarget_librelogo/locproperties` started to fail with > [build PRP] CustomTarget/librelogo/locproperties/LibreLogo_de.properties > S=C:/lo/core && I=$S/instdir && W=$S/workdir && MERGEINPUT=C:/cygwin64/tmp/gbuild.iDa6ga && PATH="C:\lo\core\instdir\program;C:\lo\core\instdir\program;$PATH" $W/LinkTarget/Executable/propex.exe -i $S/librelogo/source/pythonpath/LibreLogo_en_US.properties -o $W/CustomTarget/librelogo/locproperties/LibreLogo_de.properties -m ${MERGEINPUT} -l de && rm -rf ${MERGEINPUT} > Assertion failed: env != nullptr, file C:/lo/core/l10ntools/source/merge.cxx, line 117 > make[1]: *** [C:/lo/core/librelogo/CustomTarget_librelogo.mk:38: C:/lo/core/workdir/CustomTarget/librelogo/locproperties/LibreLogo_de.properties] Error 3 The other asserts added with a5484e496dcee9b110ef696101576a14b7a5a20e should be OK, though: * SRC_ROOT should never be empty. * WORKDIR_FOR_BUILD could presumably be empty in a cross-compilation build ($cross_compile = yes in configure.ac), but the code in l10ntools/source/localize.cxx apparently expects WORKDIR_FOR_BUILD not to be empty anyway. (And at least in a nominally cross-compilation build with --host=i686-pc-cygwin on Windows x64, $cross-compile is left empty in configure.ac and WORKDIR_FOR_BUILD is set to a non-empty value.) * ALL_LANGS should never be empty given how it is set in configure.ac, even if the code in l10ntools/source/pocheck.cxx contains an explicit if( aLanguages.isEmpty() ) check. Change-Id: I06b216587f5d76e4b5d5abc748ff34308f2e9dbb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107462 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins
2020-12-08Assert that certain env vars are set in these build-time toolsStephan Bergmann
All of those env vars are exported from config_host.mk or config_host_lang.mk. The asserts guard potential future changes from using OString to using std::string_view, where OString has an undocumented feature of allowing construction from a null pointer. Change-Id: I7bb2217fb1d38300bf169b17e9e72dafc6970b2a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107414 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-08Use OString::Concat(...) + ... instead of ... + OStringLiteral(...)Stephan Bergmann
...in some places Change-Id: Ia1d6135c89bcc18d436d8c0d353ca93195dda432 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107412 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-11-16Clean up --disable-assert-always-abort loplugin:stringviewparamStephan Bergmann
(457d76327a57303124804a201d58b52ba23ccefe "loplugin:stringviewparam (l10ntools)") Change-Id: Iebe0f61de4fd4d4744b47d17d8e3ff3f80217d18 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105929 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-11-14loplugin:stringviewparam (l10ntools)Julien Nabet
Change-Id: I9102a00e19af87de4f666d1759551be3af311fe0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105828 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-11-13tdf#123936 Formatting files in module l10ntools with clang-formatPhilipp Hofer
Change-Id: I5f8c2aec02e160a22e9ff484170303927f0c9c05 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105686 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-11-11loplugin:stringviewNoel
Add new methods "subView" to O(U)String to return substring views of the underlying data. Add a clang plugin to warn when replacing existing calls to copy() would be better to use subView(). Change-Id: I03a5732431ce60808946f2ce2c923b22845689ca Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105420 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-11disable O(U)String::concat for internal codeNoel Grandin
in favour of the more widely used, and better optimised, operator+ Change-Id: I6a1b37e0f3d253af1f7a0892443f59b620efea63 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105523 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-10new loplugin:reducevarscopeNoel Grandin
Change-Id: Iefe922c2e0d605114d54673d63eccc5e4abd545d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102143 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-16Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uStringStephan Bergmann
...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-08-28Change OUStringLiteral from char[] to char16_t[]Stephan Bergmann
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-07-01Upcoming improved loplugin:staticanonymous -> redundantstatic: l10ntoolsStephan Bergmann
Change-Id: I9b97f64f27dee5fe0c17ceaf93f7d137141be249 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97600 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-06-24add Central Kurdish (ckb) language packChristian Lohmaier
Change-Id: I007edc0e339bd9cfd8caf95ecc954628d450664f
2020-06-15Don't return too early, clean vars first (l10ntools/treemerge)Julien Nabet
Change-Id: Ib99e0897fa36bdd0c8d805e38e77c3d626c0569a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96302 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-06-10Use xmlFreeDoc since pXhpFile is a xmlDocPtr (l10ntools/treemerge)Julien Nabet
Change-Id: I32fb8824aa91464d2198c76ba9357c82ec87a0ff Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95666 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-04-15loplugin:buriedassign in l,o,p*Noel Grandin
Change-Id: Ib2dd157d43c4387eda009475311761fe2eb627cb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92241 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-04-07loplugin:flatten in l10ntoolsNoel Grandin
Change-Id: Ib1f698eddea1da2a6e06e17d1c4fec9ef717e132 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91804 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-02-03avoid flex-caused warnings about unused functionsLuboš Luňák
Change-Id: If6a028efbf2403fd92dcab914ae3197d34579392 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87869 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-01-14loplugin:finalclasses in i18npool..linguisticNoel Grandin
Change-Id: Ib903fb2fdb4c4c25f73053065b828dade8b63785 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86687 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-12-19sal_Char->char in idlc..linguisticNoel Grandin
Change-Id: Ib30fe34123ad7e5d892e8db9c742e08c4ca8fcd2 Reviewed-on: https://gerrit.libreoffice.org/85477 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-12-03remove some useless comment linesNoel Grandin
which merely announce that the next declaration is a class Change-Id: Ifdb1398bcd99816b13e0b3769b46d0562bfbc1dc Reviewed-on: https://gerrit.libreoffice.org/84229 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-11-17Extend loplugin:external to warn about enumsStephan Bergmann
To mitigate the dangers of silently breaking ADL when moving enums into unnamed namespaces (see the commit message of 206b5b2661be37efdff3c6aedb6f248c4636be79 "New loplugin:external"), note all functions that are affected. (The plan is to extend loplugin:external further to also warn about classes and class templates, and the code to identify affected functions already takes that into account, so some parts of that code are not actually relevant for enums.) But it appears that none of the functions that are actually affected by the changes in this commit relied on being found through ADL, so no adaptions were necessary for them. (clang::DeclContext::collectAllContexts is non-const, which recursively means that External's Visit... functions must take non-const Decl*. Which required compilerplugins/clang/sharedvisitor/analyzer.cxx to be generalized to support such Visit... functions with non-const Decl* parameters.) Change-Id: Ia215291402bf850d43defdab3cff4db5b270d1bd Reviewed-on: https://gerrit.libreoffice.org/83001 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-03loplugin:stringaddNoel Grandin
tweak the plugin to be more permissive, then validate by hand afterwards Change-Id: I40c5c911fe6ff7e45baaca372abf7dac211d9654 Reviewed-on: https://gerrit.libreoffice.org/81942 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-10-14loplugin:stringadd look for unnecessary temporariesNoel Grandin
which defeat the *StringConcat optimisation. Also make StringConcat conversions treat a nullptr as an empty string, to match the O*String(char*) constructors. Change-Id: If45f5b4b6a535c97bfeeacd9ec472a7603a52e5b Reviewed-on: https://gerrit.libreoffice.org/80724 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-10-02pocheck: also preserve header in check for function namesChristian Lohmaier
Change-Id: I53b67e8c690b110d2d77e100b8170ac968e35e2b
2019-10-01loplugin:stringadd in helpcompiler..ooxNoel Grandin
Change-Id: I858870d883de10a673d7ce2798bda8c8f511cee5 Reviewed-on: https://gerrit.libreoffice.org/79889 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-08-27loplugin:referencecasting find more redundant static_castNoel Grandin
Change-Id: I3a51812bbd3fcdc6b11e47cb12962f0d4fa7a2ae Reviewed-on: https://gerrit.libreoffice.org/78191 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-08-27add Silesian (szl) language packChristian Lohmaier
Change-Id: I47d9659fc21abec652a5a440004c0c2d27ec3b53
2019-08-23Mark move ctors/assignments noexceptMike Kaganski
This should enable using move semantics where possible e.g. in standard containers. According to https://en.cppreference.com/w/cpp/language/move_constructor: To make strong exception guarantee possible, user-defined move constructors should not throw exceptions. For example, std::vector relies on std::move_if_noexcept to choose between move and copy when the elements need to be relocated. Change-Id: I6e1e1cdd5cd430b139ffa2fa7031fb0bb625decb Reviewed-on: https://gerrit.libreoffice.org/77957 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-08-12Fix typosAndrea Gelmini
Change-Id: I72cc7132721706b3a5e06480efbae42065c36661 Reviewed-on: https://gerrit.libreoffice.org/77319 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2019-08-01new loplugin:mapindexNoel Grandin
Change-Id: I6b5f73b2187009e95d4d666e03e5803f522cee06 Reviewed-on: https://gerrit.libreoffice.org/76584 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-07-31Improved loplugin:stringconstant (now that GCC 7 supports it): l10ntoolsStephan Bergmann
Change-Id: I98476e17e0ab6009d822205c7b31935173da2722 Reviewed-on: https://gerrit.libreoffice.org/76666 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-07-29Fix typosAndrea Gelmini
Change-Id: Ic2fb0772648b3f93c2fdfa4d2f663b6ede2ead51 Reviewed-on: https://gerrit.libreoffice.org/76507 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2019-07-09tdf#126030 Translate automatic chart title in OOXML chartsGabor Kelemen
Add l10n support to oox module to achieve this Change-Id: I7bece62bdf5ef0f0d1ef424074f16cef94649d77 Reviewed-on: https://gerrit.libreoffice.org/74819 Tested-by: Jenkins Reviewed-by: Andras Timar <andras.timar@collabora.com>
2019-07-04cid#1448320: Resource leak in object (l10ntools/treemerge)Julien Nabet
Change-Id: I9d09d690e003d73878ef2e30da11cf079d0db441 Reviewed-on: https://gerrit.libreoffice.org/75098 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2019-06-27Ditch "using namespace U_ICU_NAMESPACE;", qualify icu:: insteadEike Rathke
geez.. for two places.. Change-Id: I4855fc92290547b0e1ca6ff5b2f10a333c6caa3f Reviewed-on: https://gerrit.libreoffice.org/74815 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2019-06-25improve loplugin:simplifyconstructNoel Grandin
Change-Id: If863d28c6db470faa0d22273020888d4219e069e Reviewed-on: https://gerrit.libreoffice.org/74559 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-04-29Related: tdf#82184 correct wrong or obsoleted LCIDs for MSIEike Rathke
This solves the cases of Oromo, Kinyarwanda and Sinhala. Kabyle is a problem on its own and apparently not easily solvable, see attempts in https://gerrit.libreoffice.org/71247 Change-Id: Id001aeba07a95f283b4cd6057c1f6e8088de940a Reviewed-on: https://gerrit.libreoffice.org/71535 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2019-04-24tdf#124791: Fix Gaelic (Scotland) (gd-GB) LCID in MSI installerMike Kaganski
... which was obviously omitted in commit 6b678c135da07f34da1bf7b19562366361e95085, which introduced the correct value of 0x0491 (1169) in addition to the pre-existing 0x043C (1084). The new value is used when user sets relevant entry in Region and Language control panel applet (intl.cpl); having the old value in MSI summary information blocks auto-detection of proper installer language. [MS-LCID] Appendix A mentions that the new code is available since Win7, so we are good with the fix. [MS-LCID] https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-lcid/a9eac961-e77d-41a6-90a5-ce1a8b0cdb9c Co-authored-by: Eike Rathke <erack@redhat.com> Change-Id: Ic03b0e8eaf145c662fde48846cd5307e362d4d63 Reviewed-on: https://gerrit.libreoffice.org/71242 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-04-13loplugin:sequentialassign in embeddedobj..l10ntoolsNoel Grandin
Change-Id: I69377e2f96a376a7a5ccaec268c4f92c00a250f7 Reviewed-on: https://gerrit.libreoffice.org/70705 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-04-03Revert "add more append methods to *StringBuffer"Noel Grandin
This reverts commit 8cfa7f4dc00f3dd37e57917ef25c806b0e9e6e73. comment from sberg: we already have 70519a43e0d89a6b5d89859a6851f8c757c6b0c7 "Replace OUStringBuffer::appendCopy with append(std::u16string_view)" (which can be extended to OStringBuffer if needed) Change-Id: Ifcc550a8cf26ef38ad49fde8b067f53c999c9276 Reviewed-on: https://gerrit.libreoffice.org/70178 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-04-03add more append methods to *StringBufferNoel Grandin
which performs the append without needing the creation of a temporary *String Change-Id: If9ad3222275f26659db2e7df8d34f068977c4d17 Reviewed-on: https://gerrit.libreoffice.org/69826 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-03-20Reduce OString operationsMatteo Casalin
Change-Id: I13291ca27574d3536e55d8207a0b13b2694385be Reviewed-on: https://gerrit.libreoffice.org/69233 Tested-by: Jenkins Reviewed-by: Matteo Casalin <matteo.casalin@yahoo.com>
2019-03-18Remove broken MergeDataHashMap optimizationStephan Bergmann
...which apparently didn't take into account that inserting into a std::unordered_map may invalidate iterators, which now started to cause build failures like > [PRP] dictionaries/hu_HU/dialog/hu_HU_de > warn:sal.osl:25175:25175:sal/osl/unx/thread.cxx:1026: RTL_TEXTENCODING_DONTKNOW -> _ASCII_US > .../gcc/trunk/inst/include/c++/9.0.1/debug/safe_iterator.h:307: > In function: > __gnu_debug::_Safe_iterator<_Iterator, _Sequence, _Category>::pointer > __gnu_debug::_Safe_iterator<_Iterator, _Sequence, > _Category>::operator->() const [with _Iterator = > std::__detail::_Node_iterator<std::pair<const rtl::OString, > std::unique_ptr<MergeData> >, false, true>; _Sequence = > std::__debug::unordered_map<rtl::OString, std::unique_ptr<MergeData> >; > _Category = std::forward_iterator_tag; > __gnu_debug::_Safe_iterator<_Iterator, _Sequence, _Category>::pointer = > std::pair<const rtl::OString, std::unique_ptr<MergeData> >*] > > Error: attempt to dereference a singular iterator. > > Objects involved in the operation: > iterator "this" @ 0x0x5a8228 { > type = std::__detail::_Node_iterator<std::pair<rtl::OString const, std::unique_ptr<MergeData, std::default_delete<MergeData> > >, false, true> (mutable iterator); > state = singular; > references sequence with type 'std::__debug::unordered_map<rtl::OString, std::unique_ptr<MergeData, std::default_delete<MergeData> >, std::hash<rtl::OString>, std::equal_to<rtl::OString>, std::allocator<std::pair<rtl::OString const, std::unique_ptr<MergeData, std::default_delete<MergeData> > > > >' @ 0x0x5a81c8 > } > /bin/sh: line 1: 25175 Aborted (core dumped) LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program" $W/LinkTarget/Executable/propex -i $S/dictionaries/hu_HU/dialog/hu_HU_en_US.properties -l de -m ${MERGEINPUT} -o $W/PropertiesTranslateTarget/dictionaries/hu_HU/dialog/hu_HU_de.properties > make[1]: *** [.../solenv/gbuild/Dictionary.mk:88: .../workdir/PropertiesTranslateTarget/dictionaries/hu_HU/dialog/hu_HU_de.properties] Error 134 with trunk libstdc++ in debug mode. Both classes MergeData and MergeDataHashMap became redundant. Change-Id: I771548a6155e14037d84acfd74cd13566a26a8d7 Reviewed-on: https://gerrit.libreoffice.org/69395 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-03-14Fix TRUE to sal_True conversion in stringMatteo Casalin
This would lead to always false condition, since that text should be uppercase. Introduced in d210c6ccc30466e98240c1409df0550514668d68. Reduce parentheses while at it. Change-Id: Iec9cbbfd0a596ad1d4dcba50aa3a5c00a54ef425 Reviewed-on: https://gerrit.libreoffice.org/69234 Tested-by: Jenkins Reviewed-by: Matteo Casalin <matteo.casalin@yahoo.com>
generated by cgit (git 2.34.1) at 2024-12-26 21:17:37 +0000