update translations for LibreOffice 4.0 rc2

Change-Id: I7c01d42e8e299f43cc9260c048c54d46b33b634c
author: Andras Timar <atimar@suse.com> 2013-01-21 11:05:36 +0100
committer: Andras Timar <atimar@suse.com> 2013-01-28 12:16:26 +0100
commit: 3303ed739a69a5cb20321d524d78b60954ba0839 (patch)
tree: 89a1a406c9e6d372de38b7850360ac8c833c9145 /source/da/scp2
parent: 15bb868bbc35ef3de6919317bec0e70883fafeea (diff)
1 files changed, 1 insertions, 1 deletions
diff --git a/source/da/scp2/source/python.po b/source/da/scp2/source/python.po
index 90bd5d9d94f..7cef478214b 100644
--- a/source/da/scp2/source/python.po
+++ b/source/da/scp2/source/python.po
@@ -12,7 +12,7 @@ msgstr ""
 "Content-Type: text/plain; charset=UTF-8\n"
 "Content-Transfer-Encoding: 8bit\n"
 "Plural-Forms: nplurals=2; plural=(n != 1);\n"
-"X-Generator: Pootle 2.5.0-beta1\n"
+"X-Generator: LibreOffice\n"
 "X-Accelerator-Marker: ~\n"
 "X-POOTLE-MTIME: 1356861735.0\n"
author	Andras Timar <atimar@suse.com>	2013-01-21 11:05:36 +0100
committer	Andras Timar <atimar@suse.com>	2013-01-28 12:16:26 +0100
commit	3303ed739a69a5cb20321d524d78b60954ba0839 (patch)
tree	89a1a406c9e6d372de38b7850360ac8c833c9145 /source/da/scp2
parent	15bb868bbc35ef3de6919317bec0e70883fafeea (diff)
Age	Commit message (Collapse)	Author
2024-12-07	Simplify a bit	Mike Kaganski
	Change-Id: Ie2b96e099a0507e14ad8e79276abdbe0f21d35f0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/178040 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2022-11-02	tdf#54857 elide more dynamic_cast	Noel Grandin
	Change-Id: I0cbdb2ee46600559d9a37f09b574d484e72a0e0d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142133 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-11-01	tdf#54857 elide more dynamic_cast	Noel Grandin
	add a helper, following the same style as the ones in sw/ Change-Id: I13c673bba5ff47df6beef9d90c200e5801030cf0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142119 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-08-29	ref-count SdrObject	Noel Grandin
	Which means we can get rid of the majestic hack of ScCaptionPtr Previously, SdrObject was manually managed, and the ownership passed around in very complicated fashion. Notes: () SvxShape has a strong reference to SdrObject, where previously it had a weak reference. It is now strong since otherwise the SdrObject will go away very eagerly. () SdrObject still has a weak reference to SvxShape () In the existing places that an SdrObject is being deleted, we now just clear the reference () instead of SwVirtFlyDrawObj removing itself from the page that contains inside it's destructor, make the call site do the removing from the page. () Needed to take the SolarMutex in UndoManagerHelper_Impl::impl_clear because this can be called from UNO (e.g. sfx2_complex JUnit test) and the SdrObjects need the SolarMutex when destructing. () handle a tricky situation with SwDrawVirtObj in the SwDrawModel destructor because the existing code wants mpDrawObj in SwAnchoredObject to be sometimes owning, sometimes not, which results in a cycle with the new code. Change-Id: I4d79df1660e386388e5d51030653755bca02a163 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138837 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-02-22	tdf#64914 slow opening large chart	Noel Grandin
	shaves 2% off the load time by avoid the cost of comphelper::getFromUnoTunnel Change-Id: I9d0438bd0ad3cf753d34fe181481f3a57193651c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130284 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-01-03	add new SvxShape hierarchy class	Noel Grandin
	to serve as a shared/common base class, so I can plumb SvxShape types through chart2. Change-Id: I8758fff1599c92a214b334ee44cf7b4e582c1915 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127873 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-09-15	Use <comphelper/servicehelper.hxx> implementing XUnoTunnel part 1	Mike Kaganski
	The header got some changes: 1. Move UnoTunnelIdInit and isUnoTunnelId into 'comphelper' namespace 2. Rename UnoTunnelIdInit to UnoIdInit, as a precondition to replace of uses of OImplementationId with it, including in XTypeProvider 3. Introduce convenience functions 'getSomething_cast' to cast between sal_Int64 and object pointers uniformly. 4. Rename getUnoTunnelImplementation to getFromUnoTunnel, both to make it a bit shorter, and to reflect its function better. Templatize it to take also css::uno::Any for convenience. 5. Introduce getSomethingImpl, inspired by sw::UnoTunnelImpl; allow it handle cases both with and without fallback to parent. 6. Adjust UNO3_GETIMPLEMENTATION_* macros TODO (in separate commits): - Drop sw::UnoTunnelImpl and sw::UnoTunnelGetImplementation - Replace all uses of OImplementationId in core with UnoIdInit - Deprecate OImplementationId in <cppuhelper/typeprovider.hxx> - Change implementations of getSomething to use getSomethingImpl - Revise uses of getSomething to use getFromUnoTunnel Change-Id: If4a3cb024130f1f552f988f0479589da1cd066e7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122022 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-07-31	getArray->getConstArray	Noel Grandin
	Change-Id: I951dd4a02c9ead98e7eb13ae2995ba2e1e57b38a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119740 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-05-02	throw() -> noexcept, part 2/3: Automatic loplugin:noexcept rewrite	Stephan Bergmann
	Change-Id: I076f16d0536b534abf0ced4d76051eadb4c0e033 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114949 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-04-15	store ptr to the original entries in SfxItemPropertyMap	Noel Grandin
	instead of copying them to a new data structure that is practically identical. Helps startup time since we build a ton of these when loading documents. And use o3tl::sorted_vector as a dense map data structure to reduce allocations and improve cache friendliness, since this is a build-once thing. Change-Id: I950be03b1a21c0c81c40f2677d4215f5e8e256cf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114015 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-02-04	use more getSdrObjectFromXShape	Noel
	Change-Id: Ia237643ab040425f231f781c86e7e060f0b53717 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110400 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-26	switching long to a 64-bit type on 64-bit windows	Noel
	() create a rewriting plugin to do most of the work, heavily based on the fakebool plugin () but there are still a number of "long"s in the codebase that will need to be done by hand (*) the plugin needs lots of handholding, due to needing to add #include and update macros Change-Id: I8184d7000ca482c0469514bb73178c3a1123b1e9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104203 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-16	Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uString	Stephan 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-28	Change 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-03-10	tdf#42949 Fix IWYU warnings in svx/source/[t-x]/cxx	Gabor Kelemen
	Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: I8d8a3e13932b004678b305f9a6883062854f9201 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90140 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-02-17	inline some acquire/release calls	Noel Grandin
	because these are all on the hot path, and in the best case, with enough inlining, the compiler can skip the call altogether and just do a locked CMPXHG instruction Change-Id: I099d6385f602e40e1767f9f1002b7514ecf436e5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88775 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-02-12	move some svx/ headers inside the module	Noel Grandin
	Change-Id: I8d9a50039a8139caebb2cfb83ca476d39432f255 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88238 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-01-28	New loplugin:unsignedcompare	Stephan Bergmann
	"Find explicit casts from signed to unsigned integer in comparison against unsigned integer, where the cast is presumably used to avoid warnings about signed vs. unsigned comparisons, and could thus be replaced with o3tl::make_unsigned for clairty." (compilerplugins/clang/unsignedcompare.cxx) o3tl::make_unsigned requires its argument to be non-negative, and there is a chance that some original code like static_cast<sal_uInt32>(n) >= c used the explicit cast to actually force a (potentially negative) value of sal_Int32 to be interpreted as an unsigned sal_uInt32, rather than using the cast to avoid a false "signed vs. unsigned comparison" warning in a case where n is known to be non-negative. It appears that restricting this plugin to non- equality comparisons (<, >, <=, >=) and excluding equality comparisons (==, !=) is a useful heuristic to avoid such false positives. The only remainging false positive I found was 0288c8ffecff4956a52b9147d441979941e8b87f "Rephrase cast from sal_Int32 to sal_uInt32". But which of course does not mean that there were no further false positivies that I missed. So this commit may accidentally introduce some false hits of the assert in o3tl::make_unsigned. At least, it passed a full (Linux ASan+UBSan --enable-dbgutil) `make check && make screenshot`. It is by design that o3tl::make_unsigned only accepts signed integer parameter types (and is not defined as a nop for unsigned ones), to avoid unnecessary uses which would in general be suspicious. But the STATIC_ARRAY_SELECT macro in include/oox/helper/helper.hxx is used with both signed and unsigned types, so needs a little oox::detail::make_unsigned helper function for now. (The ultimate fix being to get rid of the macro in the first place.) Change-Id: Ia4adc9f44c70ad1dfd608784cac39ee922c32175 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87556 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-22	Extend loplugin:external to warn about classes	Stephan Bergmann
	...following up on 314f15bff08b76bf96acf99141776ef64d2f1355 "Extend loplugin:external to warn about enums". Cases where free functions were moved into an unnamed namespace along with a class, to not break ADL, are in: filter/source/svg/svgexport.cxx sc/source/filter/excel/xelink.cxx sc/source/filter/excel/xilink.cxx svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx All other free functions mentioning moved classes appear to be harmless and not give rise to (silent, even) ADL breakage. (One remaining TODO in compilerplugins/clang/external.cxx is that derived classes are not covered by computeAffectedTypes, even though they could also be affected by ADL-breakage--- but don't seem to be in any acutal case across the code base.) For friend declarations using elaborate type specifiers, like class C1 {}; class C2 { friend class C1; }; * If C2 (but not C1) is moved into an unnamed namespace, the friend declaration must be changed to not use an elaborate type specifier (i.e., "friend C1;"; see C++17 [namespace.memdef]/3: "If the name in a friend declaration is neither qualified nor a template-id and the declaration is a function or an elaborated-type-specifier, the lookup to determine whether the entity has been previously declared shall not consider any scopes outside the innermost enclosing namespace.") * If C1 (but not C2) is moved into an unnamed namespace, the friend declaration must be changed too, see <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71882> "elaborated-type-specifier friend not looked up in unnamed namespace". Apart from that, to keep changes simple and mostly mechanical (which should help avoid regressions), out-of-line definitions of class members have been left in the enclosing (named) namespace. But explicit specializations of class templates had to be moved into the unnamed namespace to appease <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92598> "explicit specialization of template from unnamed namespace using unqualified-id in enclosing namespace". Also, accompanying declarations (of e.g. typedefs or static variables) that could arguably be moved into the unnamed namespace too have been left alone. And in some cases, mention of affected types in blacklists in other loplugins needed to be adapted. And sc/qa/unit/mark_test.cxx uses a hack of including other .cxx, one of which is sc/source/core/data/segmenttree.cxx where e.g. ScFlatUInt16SegmentsImpl is not moved into an unnamed namespace (because it is declared in sc/inc/segmenttree.hxx), but its base ScFlatSegmentsImpl is. GCC warns about such combinations with enabled-by-default -Wsubobject-linkage, but "The compiler doesn’t give this warning for types defined in the main .C file, as those are unlikely to have multiple definitions." (<https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Warning-Options.html>) The warned-about classes also don't have multiple definitions in the given test, so disable the warning when including the .cxx. Change-Id: Ib694094c0d8168be68f8fe90dfd0acbb66a3f1e4 Reviewed-on: https://gerrit.libreoffice.org/83239 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-20	Remove comphelper::OUStringLiteralList	Stephan Bergmann
	...that had been introduced with 51eb969cb77f8b54681033f4959b15ce32116b56 "Replace comphelper::ServiceInfoHelper::addToSequence" and obsoleted by <https://gerrit.libreoffice.org/#/c/83291/> "loplugin:redundantfcast: Don't warn about cast from braced-init-list" Change-Id: Ic5bb63cf4f528285587f46437a27bafbb05a07ac Reviewed-on: https://gerrit.libreoffice.org/83315 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-16	Replace comphelper::ServiceInfoHelper::addToSequence	Mike Kaganski
	Change-Id: I325e16fdf9bbbc6f2ba2d06c417da5eeb0d48023 Reviewed-on: https://gerrit.libreoffice.org/82975 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-06-17	Add comphelper::getUnoTunnelImplementation template	Arkadiy Illarionov
	Use it instead of classname::getImplementation from UNO3_GETIMPLEMENTATION_* Change-Id: Ifcc8cfcd6369c576250008c76ce31ba79ea3a596 Reviewed-on: https://gerrit.libreoffice.org/74107 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>