source/ts/dictionaries/ca.po


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

#. extracted from dictionaries/ca
msgid ""
msgstr ""
"Project-Id-Version: LibO 350-l10n\n"
"Report-Msgid-Bugs-To: https://bugs.freedesktop.org/enter_bug.cgi?product=LibreOffice&bug_status=UNCONFIRMED&component=UI\n"
"POT-Creation-Date: 2012-12-26 11:14+0100\n"
"PO-Revision-Date: 2011-10-07 14:46+0200\n"
"Last-Translator: Automatically generated\n"
"Language-Team: none\n"
"Language: ts\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: LibreOffice\n"
"X-Accelerator-Marker: ~\n"

#: description.xml
msgctxt ""
"description.xml\n"
"dispname\n"
"description.text"
msgid "Catalan spelling dictionary, hyphenation rules, and thesaurus"
msgstr ""
Age	Commit message (Collapse)	Author
2021-04-16	tdf#131634 Don't redo actions created before text edit begins.	Mark Hung
	In SdrObjEditView::SdrEndTextEdit(), pSdrUndoManager->Redo() was invoked until all the redo actions created after text edit began were converted to undo actions. Without checking, all the redo actions include the ones created before text edit began were moved to undo stack, and caused the SdrTextObj to be destroyed in SdrUndoManager::SetEndTextEditHdl when removing the undo actions and a use after release problem. The patch add GetRedoActionCountBeforeTextEdit() so the program won't invoke pSdrUndoManager->Redo() on actions created before text edit begin. Change-Id: Ic010bc6e71ee78ef2cb20a5259dc9d6d6579ccaa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114102 Tested-by: Jenkins Reviewed-by: Mark Hung <marklh9@gmail.com>
2020-11-21	tdf#123936 Formatting files in module include with clang-format	Philipp Hofer
	Change-Id: I0507dd797cd5a35e0ae14f4b69ee4e172d08a71a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105681 Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> Tested-by: Jenkins
2020-02-02	tdf#128302: Split SVXCORE_DLLPUBLIC from SVX_DLLPUBLIC	Stephan Bergmann
	Using SVX_DLLPUBLIC for both Library_svxcore and Library_svx had started to cause failures with clang-cl on Windows now, presumably due to devirtualization: > linectrl.o : error LNK2001: unresolved external symbol "protected: virtual void __cdecl SvxMetricField::DataChanged(class DataChangedEvent const &)" (?DataChanged@SvxMetricField@@MEAAXAEBVDataChangedEvent@@@Z) > linectrl.o : error LNK2001: unresolved external symbol "protected: virtual bool __cdecl SvxMetricField::PreNotify(class NotifyEvent &)" (?PreNotify@SvxMetricField@@MEAA_NAEAVNotifyEvent@@@Z) > linectrl.o : error LNK2001: unresolved external symbol "protected: virtual bool __cdecl SvxMetricField::EventNotify(class NotifyEvent &)" (?EventNotify@SvxMetricField@@MEAA_NAEAVNotifyEvent@@@Z) > linectrl.o : error LNK2001: unresolved external symbol "protected: virtual void __cdecl SvxMetricField::Modify(void)" (?Modify@SvxMetricField@@MEAAXXZ) > linectrl.o : error LNK2001: unresolved external symbol "private: virtual bool __cdecl SvxFillAttrBox::PreNotify(class NotifyEvent &)" (?PreNotify@SvxFillAttrBox@@EEAA_NAEAVNotifyEvent@@@Z) > linectrl.o : error LNK2001: unresolved external symbol "private: virtual bool __cdecl SvxFillAttrBox::EventNotify(class NotifyEvent &)" (?EventNotify@SvxFillAttrBox@@EEAA_NAEAVNotifyEvent@@@Z) > C:\lo-clang\core\instdir\program\svxcorelo.dll : fatal error LNK1120: 6 unresolved externals Replacing certain uses of SVX_DLLPUBLIC with the newly introduced SVXCORE_DLLPUBLIC (include/svx/svxdllapi.h) has been done on Linux as follows: > git grep -w --line-number -e SVX_DLLPUBLIC --and --not -e '#define SVX_DLLPUBLIC' >LINES to produce a file LINES containing all 640 uses. (Conveniently, all uses happen to be on different lines.) Manually create a file TOKENS with 640 corresponding lines, each containing the (class or function) name that is made SVX_DLLPUBLIC by in the corresponding line in LINES. Then > nm -D --def instdir/program/libsvxcorelo.so \| grep -ivw '[vw]' \| c++filt >SVXCORESYMS > nm -D --def instdir/program/libsvxlo.so \| grep -ivw '[vw]' \| c++filt >SVXSYMS > n=$(cat TOKENS \| wc -l) > for ((i=1;i<="$n";++i)); do > tok=$(head -n "$i" TOKENS \| tail -1) > printf @ > grep -Fw "$tok" SVXCORESYMS >/dev/null && printf svxcore > printf @ > grep -Fw "$tok" SVXSYMS >/dev/null && printf svx > printf '@ ' > head -n "$i" LINES \| tail -1 > done to generate 640 output lines detailing for each SVX_DLLPUBLIC name occurrene whether it is mentioned in exports from neither (@@@), only from svx (@@svx@), only from svxcore (@svxcore@@), or from both libraries (@svxcore@svx@). The numbers that gives is 10 @@@ 180 @@svx@ 424 @svxcore@@ 26 @svxcore@svx@ The 10 @@@ ask for follow-up clean up, but most of them are just left as SVX_DLLPUBLIC for now. The exceptions are sxv::ITextProvider (include/svx/itextprovider.hxx) and SdrCustomShapeGeometryItem::PropertyPairHash (include/svx/sdasitm.hxx, where PropertyPairHash is a member struct of SVXCORE_DLLPUBLIC SdrCustomShapeGeometryItem). Keeping them as SVX_DLLPUBLIC would cause "unresolved externals" errors when linking Library_svxcore on Windows. The 180 @@svx@ are fine to keep as-is, and the 424 @svxcore@@ need rewriting. The 26 @svxcore@svx@ needed manual inspection to decide (in some cases, the chosen name in TOKENS was a too generic function name like Fill, in other cases it was the name of a class exported from one library but also mentioned in the arguments of a function exported from the other). And for sdr::table::SdrTableObj the class itself is defined in svxcore while the static member functions ExportAsRTF and ImportAsRTF are defined in svx. But MSVC does not allow to mark the class as SVXCORE_DLLPUBLIC and the two static member functions as SVX_DLLPLUBIC, so move the two functions out of the class. (There appears to be no real necessity that they were static member functions in the first place; they don't even need to be friends of the class. Nevertheless, this mixture of functionality from svxcore and svx in include/svx/svdotable.hxx may ask for follow-up clean up, one way or another.) All the output lines that need rewriting (all the @svxcore@@ ones, and the manually picked subset of @@@ and @svxcore@svx@ ones) are copied into a new file CHANGE (containing 451 lines). Then > sed -E -e 's\|^@.@.@ ([^:]+):([0-9]+):.*$\|sed -i -e "\2 s/SVX_DLLPUBLIC/SVXCORE_DLLPUBLIC/" \1\|' <CHANGE >COMMANDS > . COMMANDS to do the changes. Change-Id: If9b6dd1c9e9ba2eb883dbdac4385d28c6fc8a203 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87794 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-09-03	loplugin:constmethod in svx	Noel Grandin
	Change-Id: I6ae7c04479e3ea8ecd7535c33224a5e7095b64bb Reviewed-on: https://gerrit.libreoffice.org/78396 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-07-25	tdf#47807 Invalidate bindings to Undo Redo	Jim Raykowski
	This patch reverts the previous commit made for this and provides a new fix. Change-Id: I487ecf0a7564f1130ef9a42e893e73185701d8c9 Reviewed-on: https://gerrit.libreoffice.org/76287 Tested-by: Jenkins Reviewed-by: Jim Raykowski <raykowj@gmail.com>
2019-07-25	tdf#47807 Invalidate bindings to Undo Redo	Jim Raykowski
	Change-Id: I71a16e60395003402372202a755b976d37690a27 Reviewed-on: https://gerrit.libreoffice.org/76146 Tested-by: Jenkins Reviewed-by: Jim Raykowski <raykowj@gmail.com>
2019-05-27	tdf#42949 Fix IWYU warnings in include/svx/[sS][a-h]*	Gabor Kelemen
	Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: I84fc75e06e61e5391aef6e237c36daad95dedb84 Reviewed-on: https://gerrit.libreoffice.org/72550 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-02-27	loplugin:unusedfields look for classes where we can make all the..	Noel Grandin
	fields private Change-Id: Id3c6b123f06ab5dcf87628de4c347626110d2d27 Reviewed-on: https://gerrit.libreoffice.org/68302 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-12-07	lokit: add .uno:DocumentRepair command	Henry Castro
	Change-Id: I5b13ea6f4785bc91c29111fa63c4a1b0ea9b2660 Reviewed-on: https://gerrit.libreoffice.org/38908 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Henry Castro <hcastro@collabora.com>
2017-04-05	loplugin:constantparam	Noel Grandin
	Change-Id: I1996319e5b664dff95f7a9b2346aea6092d333ec Reviewed-on: https://gerrit.libreoffice.org/36070 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2016-09-13	loplugin:override: No more need for the "MSVC dtor override" workaround	Stephan Bergmann
	The issue of 362d4f0cd4e50111edfae9d30c90602c37ed65a2 "Explicitly mark overriding destructors as 'virtual'" appears to no longer be a problem with MSVC 2013. (The little change in the rewriting code of compilerplugins/clang/override.cxx was necessary to prevent an endless loop when adding "override" to OOO_DLLPUBLIC_CHARTTOOLS virtual ~CloseableLifeTimeManager(); in chart2/source/inc/LifeTime.hxx, getting stuck in the leading OOO_DLLPUBLIC_CHARTTOOLS macro. Can't remember what that isAtEndOfImmediateMacroExpansion thing was originally necessary for, anyway.) Change-Id: I534c634504d7216b9bb632c2775c04eaf27e927e
2015-10-12	Replace "SAL_OVERRIDE" with "override" in LIBO_INTERNAL_ONLY code	Stephan Bergmann
	Change-Id: I2ea407acd763ef2d7dae2d3b8f32525523ac8274
2015-09-08	convert Link<> to typed	Noel Grandin
	Change-Id: I2977a0fcd18bd719b30cb4100501058884069572