update translations for 6.1.0 rc1

and also test the auto-update of the core module Change-Id: Id4556effa916c1d274f818bb5a5b700617fa6436
author: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> 2018-07-04 22:36:20 +0200
committer: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> 2018-07-04 22:36:20 +0200
commit: be22e619a5440e0e9b8aed19734bac8401220896 (patch)
tree: d50725997e72cb59c98e4c26d0f3dad16f0a8873 /source/ta/svx/messages.po
parent: ed578ffce83e204db7ea027489e00e6ceed21d3b (diff)
1 files changed, 19 insertions, 4 deletions
diff --git a/source/ta/svx/messages.po b/source/ta/svx/messages.po
index 9e0d1443092..c61bc8169cf 100644
--- a/source/ta/svx/messages.po
+++ b/source/ta/svx/messages.po
@@ -3,7 +3,7 @@ msgid ""
 msgstr ""
 "Project-Id-Version: PACKAGE VERSION\n"
 "Report-Msgid-Bugs-To: https://bugs.libreoffice.org/enter_bug.cgi?product=LibreOffice&bug_status=UNCONFIRMED&component=UI\n"
-"POT-Creation-Date: 2018-07-02 00:13+0200\n"
+"POT-Creation-Date: 2018-07-04 21:22+0200\n"
 "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
 "Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
 "Language-Team: LANGUAGE <LL@li.org>\n"
@@ -2277,18 +2277,18 @@ msgctxt "classificationdialog|label-IntellectualProperty"
 msgid "Intellectual Property"
 msgstr ""
 
-#: svx/uiconfig/ui/colorwindow.ui:59
+#: svx/uiconfig/ui/colorwindow.ui:60
 #, fuzzy
 msgctxt "colorwindow|none_color_button"
 msgid "None"
 msgstr "எதுவுமில்லை"
 
-#: svx/uiconfig/ui/colorwindow.ui:128
+#: svx/uiconfig/ui/colorwindow.ui:146
 msgctxt "colorwindow|label1"
 msgid "Recent"
 msgstr "சமீபத்திய"
 
-#: svx/uiconfig/ui/colorwindow.ui:162
+#: svx/uiconfig/ui/colorwindow.ui:183
 msgctxt "colorwindow|color_picker_button"
 msgid "Custom Color…"
 msgstr "தனிப்பயன் நிறம்…"
@@ -4607,6 +4607,21 @@ msgctxt "namespacedialog|label1"
 msgid "Namespaces"
 msgstr "பெயர்வெளிகள்"
 
+#: svx/uiconfig/ui/oldcolorwindow.ui:59
+msgctxt "oldcolorwindow|none_color_button"
+msgid "None"
+msgstr ""
+
+#: svx/uiconfig/ui/oldcolorwindow.ui:128
+msgctxt "oldcolorwindow|label1"
+msgid "Recent"
+msgstr ""
+
+#: svx/uiconfig/ui/oldcolorwindow.ui:162
+msgctxt "oldcolorwindow|color_picker_button"
+msgid "Custom Color…"
+msgstr ""
+
 #: svx/uiconfig/ui/optgridpage.ui:63
 msgctxt "optgridpage|usegridsnap"
 msgid "_Snap to grid"
author	Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>	2018-07-04 22:36:20 +0200
committer	Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>	2018-07-04 22:36:20 +0200
commit	be22e619a5440e0e9b8aed19734bac8401220896 (patch)
tree	d50725997e72cb59c98e4c26d0f3dad16f0a8873 /source/ta/svx/messages.po
parent	ed578ffce83e204db7ea027489e00e6ceed21d3b (diff)
Age	Commit message (Collapse)	Author
2024-07-29	use more GetItemSurrogatesForItem	Noel Grandin
	since it is considerably more efficient Change-Id: I224ff890f6dd52481621b46f912f1e8dbf65126c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171182 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-11	loplugin:ostr in svx	Noel Grandin
	Change-Id: Ia765a03e033acb82e367873380d289587ea87d6c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167449 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-01-19	ITEM: Needed reworks on ItemSurrogate mechanism	Armin Le Grand (allotropia)
	ItemSurrogates are a possibility to iterate over all SfxPoolItems associated with a WhichID at a ItemPool to collect or change data. It is in general not a good idea: the correct action would be to iterate over the model data and change/ adapt/collect data on the Items of the type in question. This is because the assumtion that you iteate over all the Items associated with a document model is not correct: The ItemPool of the model is used for various ItemSets, e.g. Dialogs/Sidebar and others, so you might get Items not only from the DocumentModel but from elsewhere. You might even get Items from other models, so changing these might have unpredictable effects (!) It is clear to me that this mechanism is more convenient that iterating over the document models, and it might have been invented due to this and then used in more and maore cases. There should be a lambda/callback-based mechanism in every document model to do this. Until then we have to live with this 'compromize'. There are over 100 usages currrently, so no way to easily replace this. For those reasons I changed this to be more safe: There are two methods to do this now: 1: iterateItemSurrogates to allow read/write access. I identified six places where that mechanism was used to change SfxPoolItems, with the use of const_cast. This now offers a lambda/callback mechanism and the needed data in a helper (SurrogateData). Internally it iterates over ItemSets and ItmHolders registered and thus associated with the Pool. Changing an Item means to set a changed Item at the Pool/replace the holder. 2: GetItemSurrogates/FindItemSurrogate to allow read-only iteration (2nd one with filter). This collects the Items in a vector that you provide over which you can then iterate. Do not use const_cast and change the Item when using this (!) Note that mechanism (2) pe-filters the Items so that you get each only once: Of couse one Item can be set in more than one ItemSet/Holder (but also in more than one model). This filtering is not possible for (1), you have to evtl. do the same replace action for the same item, but this is the only way to not change Items that are associated wth another model. Note that (2) could also be changed to a lambda/callback mechanism similar to (1), but there are too many places that would beed to be adapted. That would have the advantage to not need to pre-collect the candidates in a first run. Also removed/replaced FindItemSurrogate with using GetItemSurrogates and locally filtering with that needle. That also made me remove/cleanup CollectSurrogates, it's only used in one place now. Change-Id: I0fe2f51f4fca45e1e5aea032cb96bb77b4567f4d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162254 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2024-01-12	ITEM: No longer register Items at Pool	Armin Le Grand (allotropia)
	The issue is that the flag RegisteredAtPool at the SfxPoolItem is Pool-dependent: It marks that the Item is registeres at one Pool/Model. This makes it Pool-dependent. Due to this there is no way to share Items that need to be registered globally/ in multiple Pools/Models what is one of the goals for optimal sharing. We can also not live without having access to all Items associated with the Pool, due to mechanisms in place like the Surrogate stuff. This again is used for two purposes: (1) Access all Items associated with one Pool/Model, at least that is the assumption. This is not valid since it gets corrupted with a single ItemSet/Holder used that does not host model data, e.g. an open Dialog or the Sidebar (or...). But works in principle. (2) Access extra-Items that are held nowhere and are created using DirectPutItemInPool, e.g. infos for a Dialog. These would need a instance/place to host them, the Pool is (ab)used for that. Both are 'compromizes' (to not use a more bad word) and should not exist. (1) should iterate over the Model and do actions. There are even places that use (1) to change Items, by casting them to non-const, even RefCounted ones, so having no control over what all might be changed doing so. Since we talk about ca. 100+ places there is no way to get away from this - I can imagine how this happened: The 'poolable' attr traditionally needed for the old binary format was one day 'used' to not need to iterate over the Model, an API was added to access and this usage was copied. Sigh.. It is even used when ODF is loaded: E.g. the FillStyle is imported from XML, interpreted, and put into an ItemSet. Then it gets set at the XShape using UNO API and a name -> that name and the Surrogate mechanism is used to find and set the FillStyle at the Model Object. The FillStyle could probably just be set using UNO API and the data directly. The association between Model/Pool and Item is created by the object hosting the Item, these are ItemSets and ItemHolders. Thus it is possible to register these at the Pool. This allows to iterate and collect the Items associated with the Pool and keep the Surrogate mechanism alive. This is the main change done here. It limits the registrations to Items for which (at the Pool) the NeedsPoolRegistration is set, also Item-independent. Speed is okay, I saw no big changes in my tests here. The registration is just pointers, no ownership or RefCounting needed here. The advantage is that Items get closer to be shared office-wide, they can be referenced by multiple ItemSets (RefCnt) associated with different Pools/Models. NOTE: This is not true for SfxSetItems, these are and will stay Pool-dependent due to their need to a Pool in the contained ItemSet. Note that we have ca. six deivations of SfxSetItem, but ca. 500+ Item derivations, so not too bad. For the usages of Surrogates to change existing, RefCounted Items: These can now at least be changed - if they show up to be problematic - to iterate over the registered ItemSets and change Items there the correct way: Set a changed one at the ItemSet. That also allows Objects to react on ItemChanges, there is no way to do that with the existing 'compromize'... UnitTests show that this already works well for SC and SD, but SW has still some issues. I will put this to gerrit now, but there will be additional work. A involved problem is the current DefaultItem handling and the state the Pool implementation is in. E.g. StaticDefaults are not really static, Pools hard-delete the DefaultItems (forcing the RefCnt to zero to not have the destructor complain) and other quirks. Looking at that right now, hoping to get this change done without having to change that too much. I thought about adapting PoolItemTest to this, but it is only related to DirectPutItemInPool which is mostly gone and hopefully completely soon. Nonetheless I adapted that mechanism to use a list of SfxPoolItemHolder at the Pool. That makes it safe and abandons the need for indirect garbage collection removal at the Pool. Change-Id: Ib47f21dafa989202930919eace5f7e9c5632ce96 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161896 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2021-10-06	use SfxItemSetFixed in svx	Noel Grandin
	Change-Id: I2b31d586ace6720b9bfc223f78874bf347d64521 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123143 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-07-19	Move svl::Items to include/svl/whichranges.hxx, and unify its usage	Mike Kaganski
	... in WhichRangesContainer and SfxItemSet ctors. Now it's not needed to explicitly use 'value' in WhichRangesContainer's ctor, or create an instance for use in SfxItemSet ctor (svl::Items is already defined as a template value of corresponding type). Instead of WhichRangesContainer Foo(svl::Items<1, 2>::value); SfxItemSet Bar(rItemPool, svl::Items<1, 2>{}); now use: WhichRangesContainer Foo(svl::Items<1, 2>); SfxItemSet Bar(rItemPool, svl::Items<1, 2>); Change-Id: I4681d952b6442732025e5a26768098878907a238 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119157 Tested-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-07-16	tdf#92796 ODF import: remove unused bitmap fills	Michael Stahl
	With CWS impress64 a partial fix for this was implemented to drop unreferenced named items including all non-color fills after ODF import, but this is only done in sd so move the code that does that to svx and call it from sc and sw as well. Implement some UNO interface for this, it's at least better than a magic string, and not obvious how a better solution would look like since it's known only at the end of the import if a bitmap is used or not. Another problem: when the Area tab is used to change to a different kind of fill, the items with the details for the previous fill aren't cleared, and so they are written to ODF files. Hence bitmaps in the file can be referenced even if they aren't actually used, and bloat up the files. Fix this by dropping all unused draw:fill-image-name attributes in ODF import. Also do the same for Gradient and Hatch fills; Transparency gradients can be combined with anything so leave them as they are. Change-Id: I0b591fd9f963d974d0c3e7208b99621ad61dd93c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118950 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
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>
2020-11-24	loplugin:stringviewparam extend to comparison operators	Noel
	which means that some call sites have to change to use unicode string literals i.e. u"foo" instead of "foo" Change-Id: Ie51c3adf56d343dd1d1710777f9d2a43ee66221c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106125 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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>
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>