lo/translations - LibreOffice 界面翻译代码仓库

Age	Commit message (Collapse)	Author
2013-06-27	update Sidama translation	Andras Timar
	Change-Id: I2d52fb99fe95c99b54e9242bb009f308aaf21b6e
2013-05-25	initial import of 4.1 translations	Andras Timar
	Change-Id: Ia93f31dedcdff3e180c36473e0667022795d96a7
2013-05-07	update translations for LibreOffice 4.0.3 rc1	Andras Timar
	Change-Id: I4a1d49dbef58c048aa57a29bec7623d4ad31920d
2013-01-06	update translations for LibreOffice 4.0 rc1	Andras Timar
	Change-Id: I85ba7031ebee3b3b0108218e97093fab1e9d84a3
2012-12-16	update translations for LibreOffice 4.0 beta2	Andras Timar
	Change-Id: Iff858adb848a543f565e3c0df33c8398c74c754d
2012-12-03	update translations for LibreOffice 4.0 beta1	Andras Timar
	Change-Id: I35e0bf7dfef1541f76508edb962e89bc5d78e339
2012-11-20	initial import of LibreOffice 4.0 translations	Andras Timar
	Change-Id: I577494b6b4189ed19723af4b5e273ea4da85e708

Age	Commit message (Collapse)	Author
11 days	ITEM: Refactor ItemType	Armin Le Grand (Collabora)
	ItemType is useful and faster than RTTI. Until now it was implemented by a 16-bit member in the base class, plus (potentially) all constructors having to hand a value in at item construction type (of type SfxItemType) to get that member set correctly. This works, but there is no reliable way to guarantee coverage, and there have already been cases with missing SfxItemType - these fallback to '0' and thus all Items with ItemType() == 0 are assumed equal and might be static_cast'ed to the wrong classes. Note that I identified 35 Items that had no correct ItemType set/implemented actually. It also uses 16-bit per incarnated Item at runtime. I thought and realized now a more systematic approach to do that with a pure virtual function at the Item itself. That can also be secured by a clang compiler plugin in the future to keep it working. It uses one virtual function per derived class, no longer space in incarnated Items. Also the constructors will get more simple again. But the main aspect is security - we cannot afford Items potentially being held as equal if they are not. Unfortunately C++ does not offer something like a 'strict pure virtual function' that would force to be overloaded in every derivation, but the used methotology and adding a clang test is reasonably safe. Have now done the cleanup of previous method. Change-Id: I04768285f1e9b73d64b0bb87df401944b5d35678 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180017 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2022-08-07	clang-tidy modernize-pass-by-value in sc	Noel Grandin
	Change-Id: Ia7ff651d1cbc119b36a9f8052594d03650988f59 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137848 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-03-01	make Calc jumbo sheets an explicit build feature	Luboš Luňák
	On 32bit platforms tools::Long is 32bit, which is not enough for pixel coordinates with 1m+ Calc rows+. So do not allow jumbo sheets for such platforms. Change-Id: I2ebd56a051470d33fca967918af3e7d2b0172dc7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130713 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-03-23	tdf#124176 Use pragma once in s*	Vincent LE GARREC
	sc, scaddins, sccomp, scripting Change-Id: Ia99fec9e238033821cb784810edd4762c09bd5db Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112049 Tested-by: Jenkins Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
2020-03-12	Revert "loplugin:constfields in sc"	Noel Grandin
	This reverts commit fb1d3b580763a333bbbfe115d09e1b5cd8849675. Now that we know that making fields has negative side effects like disabling assignment operator generation. Change-Id: Ib48334ffbeb2c768896dd8ced6818aa0b9910b0b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90333 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>