Updated Slovenian translation

Change-Id: If92bf4315d62bbd31c9c42c40f0673b240c1853b
author: Andras Timar <andras.timar@collabora.com> 2018-10-21 15:54:08 +0200
committer: Andras Timar <andras.timar@collabora.com> 2018-10-21 15:54:08 +0200
commit: 7bf607deb6711d47520579b6cdc0381cb71420da (patch)
tree: 5135515834db5d222b80fca39a35a3838a2df6cd /source/sl/desktop/messages.po
parent: 1972d9c3c26f6064e42870aeae397db7ea3423a6 (diff)
1 files changed, 7 insertions, 7 deletions
diff --git a/source/sl/desktop/messages.po b/source/sl/desktop/messages.po
index b0455793a53..83f36e40883 100644
--- a/source/sl/desktop/messages.po
+++ b/source/sl/desktop/messages.po
@@ -1,10 +1,10 @@
 #. extracted from desktop/inc
 msgid ""
 msgstr ""
-"Project-Id-Version: LibreOffice 6.0\n"
+"Project-Id-Version: LibreOffice 6.2\n"
 "Report-Msgid-Bugs-To: https://bugs.libreoffice.org/enter_bug.cgi?product=LibreOffice&bug_status=UNCONFIRMED&component=UI\n"
-"POT-Creation-Date: 2018-04-23 10:45+0200\n"
-"PO-Revision-Date: 2014-10-09 14:06+0200\n"
+"POT-Creation-Date: 2018-10-05 15:08+0200\n"
+"PO-Revision-Date: 2018-09-16 16:19+0200\n"
 "Last-Translator: Martin Srebotnjak <miles@filmsi.net>\n"
 "Language-Team: sl.libreoffice.org\n"
 "MIME-Version: 1.0\n"
@@ -12,8 +12,8 @@ msgstr ""
 "Content-Transfer-Encoding: 8bit\n"
 "Language: sl\n"
 "Plural-Forms: nplurals=4; plural=(n%100==1 ? 0 : n%100==2 ? 1 : n%100==3 || n%100==4 ? 2 : 3);\n"
-"X-Accelerator-Marker: ~\n"
 "X-Generator: Virtaal 0.7.1\n"
+"X-Accelerator-Marker: ~\n"
 "X-Poedit-SourceCharset: UTF-8\n"
 "X-Project-Style: openoffice\n"
 
@@ -641,7 +641,7 @@ msgid "The path manager is not available.\n"
 msgstr "Upravljalec poti ni na voljo.\n"
 
 #: desktop/inc/strings.hrc:177
-msgctxt "STR_BOOSTRAP_ERR_NOTENOUGHDISKSPACE"
+msgctxt "STR_BOOTSTRAP_ERR_NOTENOUGHDISKSPACE"
 msgid ""
 "%PRODUCTNAME user installation could not be completed due to insufficient free disk space. Please free more disc space at the following location and restart %PRODUCTNAME:\n"
 "\n"
@@ -650,12 +650,12 @@ msgstr ""
 "\n"
 
 #: desktop/inc/strings.hrc:178
-msgctxt "STR_BOOSTRAP_ERR_NOACCESSRIGHTS"
+msgctxt "STR_BOOTSTRAP_ERR_NOACCESSRIGHTS"
 msgid ""
 "%PRODUCTNAME user installation could not be processed due to missing access rights. Please make sure that you have sufficient access rights for the following location and restart %PRODUCTNAME:\n"
 "\n"
 msgstr ""
-"Uporabniške namestitve %PRODUCTNAME ni mogoče zaključiti zaradi neustreznih pravic dostopa. Preverite, da imate zadostne pravice za dostop do navedenega mesta in ponovno zaženite %PRODUCTNAME:\n"
+"Uporabniške namestitve %PRODUCTNAME ni mogoče obdelati zaradi neustreznih pravic dostopa. Preverite, da imate zadostne pravice za dostop do navedenega mesta in ponovno zaženite %PRODUCTNAME:\n"
 "\n"
 
 #: desktop/inc/strings.hrc:180
author	Andras Timar <andras.timar@collabora.com>	2018-10-21 15:54:08 +0200
committer	Andras Timar <andras.timar@collabora.com>	2018-10-21 15:54:08 +0200
commit	7bf607deb6711d47520579b6cdc0381cb71420da (patch)
tree	5135515834db5d222b80fca39a35a3838a2df6cd /source/sl/desktop/messages.po
parent	1972d9c3c26f6064e42870aeae397db7ea3423a6 (diff)
Age	Commit message (Collapse)	Author
2023-08-21	move BGradient to awt::Gradient2 UNO conversion into docmodel	Tomaž Vajngerl
	This is needed because the module dependencies are an issues if the conversion is done in basegfx. The bigger issue will come when the ComplexColor conversion will be done as basegfx can't depend on docmodel because of circular dependencies. The BGradient is also more suitable for docmodel anyway as the previously it was part of the model and is not a basic (gfx) type - however this doesn't move the whole BGradient into docmodel yet. Change-Id: Id91ce52232f89f00e09b451c13da36e2854ae14b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155674 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-05-19	MCGR: Adaptions to WriteGradientFill and BGradient	Armin Le Grand (allotropia)
	Added code to make WriteGradientFill directly use the available BGradient implementation. The goal is to never directly work on awt::Gradient2, but use BGradient & it's tooling methods. Added constructors and tooling to BGradient and BColorStops to make that easier (single line conversions between uno::Any, basesgfx classes and awt:: incarnations). Directly handle uno::Any and awt:: classes, changed stuff to make use of this. Change-Id: I083a323b9efee8ca4f3becb2966aac0a294b9a60 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151842 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-05-15	MCGR: consolidations/cleanups for changes so far	Armin Le Grand (allotropia)
	Change-Id: I85cf40e4803b0485bb40349d8e81adc8123666c4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151706 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-04-23	cid#1524676 try to convince coverity of the error of its ways	Caolán McNamara
	and cid#1524745 Explicit null dereferenced Change-Id: Id2fb9cf6d0a71712533e14981a33490c578db597 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150818 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2023-04-19	MCGR: 2nd corrections/adaptions to MCGR	Armin Le Grand (allotropia)
	Adapted handling of 'border' argument from our gradients for oox export, so that it looks the same. Also added quite some cases to peserve in-between GradientStops for current UI implementations to be able to edit the gradients as usual without losing the in-between GradientStops. While we will not be able to modify these, we are at least able to modify all the other gradient attributes, including start/endColor. Done this for TransparencyGradients, too. Also moved more stuff to the gradient tooling in basegfx. Change-Id: I6e94011bbf3715baa1401ab97e5b59811298342f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150577 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-03-19	MCGR: Model data changes for ColorSteps	Armin Le Grand (allotropia)
	Added tooling replaceStart/EndColor to allow simple transition for code that does not immediately adapt to multi color gradients. Also added createColorStepsFromStartEndColor for the same purpose. Adapted XGradient to no longer have Start/EndColor at all, but only use ColorSteps. Adapted all usages of XGradient to no longer use Get/Set/Start/EndColor, but access the ColorSteps instead. Replaced quite some XGradient constructors that used XGradient() as Start/EndColor since this is already the default. Adapted ColorBlending to black AKA Start/EndIntens in XGradient to work now on all ColorSteps in the required linearly-scaled manner. UNO API changes: Added com::sun::star::awt::ColorStep as basic data element that holds a pair of Offset and Color. Added com::sun::star::awt::ColorStepSequence to handle an array of sorted entries. Added com::sun::star::awt::Gradient2 derived from com::sun::star::awt::Gradient, extended by the needed com::sun::star::awt::ColorStepSequence. Added MID_GRADIENT_COLORSTEPSEQUENCE to UNO API to provide access to ColorSteps directly. Adapted XFillGradientItem::QueryValue/PutValue to make use of new UNO API data structures. To do so, added tooling methods for data transition: - fillColorStepSequenceFromColorSteps - fillGradient2FromXGradient - fillColorStepsFromAny - fillXGradientFromAny and adapted - case '0' (all data) - MID_FILLGRADIENT - MID_GRADIENT_COLORSTEPSEQUENCE - MID_GRADIENT_START/ENDCOLOR to make use of these. Tested usage of these in the office. Renamed from GradientStep to GradientStop after discussions with members on the list to make this closer related to other norms/definitions. Also renamed classes and class members to better reflect to GradientStop, so grepping/finding will be easier (e.g. 'Color' just exists pretty often, but 'StopColor' is more precise). Changed the used UNO API class for reprsenting the Color to better reflect to ranges [0.0 .. 1.0] and usage of RGB. Change-Id: I1eeb3e97e81d6785967615d1ff256551fc3b882d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148849 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2022-07-14	loplugin:moveit	Noel Grandin
	Change-Id: I2702e716dc669ffbb870d36d060e110288d7a744 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137043 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-05-25	SvxUnoXPropertyTable is never passed a null ptr	Noel Grandin
	and make the type of the constructor functions more precise to avoid unnecessary UNO_QUERY at the call site Change-Id: I8164fd3df131720cf86eaf6d49735a3157d3cc97 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134914 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-01-16	make the Color constructors explicitly specify transparency	Noel
	to reduce the churn, we leave the existing constructor in place, and add a clang plugin to detect when the value passed to the existing constructor may contain transparency/alpha data. i.e. we leave expressions like Color(0xffffff) alone, but warn about any non-constant expression, and any expression like Color(0xff000000) Change-Id: Id2ce58e08882d9b7bd0b9f88eca97359dcdbcc8c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109362 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-10-21	new tools::Degree10 strong typedef	Noel Grandin
	partly to flush some use of "long" out the codebase, but also to make it obvious which units are being used for angle values. Change-Id: I1dc22494ca42c4677a63f685d5903f2b89886dc2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104548 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-03-13	Revert "loplugin:constfields in svx"	Noel Grandin
	This reverts commit 1a6397030381a45f27ab7a2a02e6e6d0f9987c84. Change-Id: Iaa706bb4ea3144ef57ab359b982400abc589b97e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90454 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>
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>
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-08-17	tdf#88205 Adapt uses of css::uno::Sequence to use initializer_list ctor	Julien Nabet
	in svx Change-Id: I70cba5dbfed9b2bbfe82d89c9dc6a5875c953bd3 Reviewed-on: https://gerrit.libreoffice.org/77649 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2019-07-31	Improved loplugin:stringconstant (now that GCC 7 supports it): svx	Stephan Bergmann
	Change-Id: Idbdee862f96a3d9e6baaa7203528a423c017eb80 Reviewed-on: https://gerrit.libreoffice.org/76640 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-04-30	drop Graphic::operator bool	Noel Grandin
	which tends to interact in very weird ways with other code, for example it makes Graphic appear to have an operator< Change-Id: I335fe8f3644b710bc61291e625cbca7334a37716 Reviewed-on: https://gerrit.libreoffice.org/71532 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2019-02-12	o3tl::make_unique -> std::make_unique in svx/	Gabor Kelemen
	Since it is now possible to use C++14, it's time to replace the temporary solution with the standard one Change-Id: Ic91b7170b10299001167e78ade1d24c16ce9319e Reviewed-on: https://gerrit.libreoffice.org/67475 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2018-10-08	loplugin:constfields in svx	Noel Grandin
	Change-Id: I643e8686e015ca85dd96221f1c93038f4fddf27b Reviewed-on: https://gerrit.libreoffice.org/61182 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>