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

Age	Commit message (Expand)	Author
2014-10-29	Updated Slovenian translation	Andras Timar
2014-05-18	Updated Slovenian translation	Andras Timar

Age	Commit message (Collapse)	Author
2024-05-03	makefile simplification: replace $(call gb_CustomTarget_get_workdir,foo)	Christian Lohmaier
	…by a simple/static $(gb_CustomTarget_workdir)/foo The build system has a lot of overly complicated leftovers from when it was introduced and had not only deal with split repositories but also had to coexist with another buildsystem. Along with lots of copy'n'paste along the years the makefiles became hard to grasp for newcomers with all our calls and evals. As a first step to streamline that, the macros from TargetLocations that simply prefix a static path to the argument (and similar of the same kind) are a natural pick before simplifying the rules themselves/getting rid of a bunch of eval statements. Change-Id: Ia06dbbcd5d1994755a2ff05b84f72ccbc4e3cab5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167005 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2023-04-11	allow native compile for windows aarch64	Christian Lohmaier
	using both --host=aarch64-pc-cygwin and --build=aarch64-pc-cygwin on a suitable system. Change-Id: Id11e25b03de8dd8dd52c63e7a06d57d44e3fce33 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150053 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2021-04-07	Updated README.md files to represent current code / use Markdown format	Hossein
	Previously, all of the README files have been renamed to README.md and now, the contents of these files were changed to use Markdown format. Other than format inconsistency, some README.md files lacked information about modules, or were out of date. By using LibreOffice / OpenOffice wiki and other documentation websites, these files were updated. Now every README.md file has a title, and some description. The top-level README.md file is changed to add links to the modules. The result of processing the Markdown format README.md files can be seen at: https://docs.libreoffice.org/ Change-Id: Ic3b0c3c064a2498d6a435253b041df010cd7797a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113424 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2021-03-24	Using .md extension/Markdown syntax for modules README	Hossein
	Renaming all README files for all top level modules to README.md, applying no content change at this stage to be able to track history of the files. These files should be edited to use correct Markdown syntax later. Change-Id: I542fa3f3d32072156f16eaad2211a397cc212665 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112977 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2021-03-23	Rename LO Windows arm64 ID to aarch64	Jan-Marek Glogowski
	The Windows platform is called Arm64. But now that the ID for Mac is also going to be renamed from arm64 to aarch64, this get's rid of the arm64 as the UNO identifier and user in gbuild, just like on all other Arm64 platforms. Change-Id: I60a7eafd04b426f17b6e41ad9a09e6405c0d4173 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112973 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-09-17	cli_ure: Disable .NET for Windows Arm64 build	Jan-Marek Glogowski
	The current .NET 5.0 Arm64 preview doesn't have a mscoree.lib, so linking the climaker isn't possible. Change-Id: Ibbac88aa465a9ca2eb8fb0efaad91d20f358229b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102858 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-08-05	add dependency to juh,jurt,ridl,unoil poms	Rene Engelhard
	They are dummies now and empty (except Class-Path:). Thus maven should pull in libreoffice.jar, too Change-Id: I63753deddceef6480fd4f5122b4892b707a9dd20 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98929 Tested-by: Jenkins Reviewed-by: David Ostrovsky <david@ostrovsky.org>
2020-05-06	Move all public Java classes to libreoffice.jar	Samuel Mehrbrodt
	This moves the classes from juh.jar and ridl.jar to libreoffice.jar The goal is to have one single jar (and Java module, will be added later) which developers can include to work with LO. juh.jar and ridl.jar are kept as basically empty jars with libreoffice.jar on its classpath to keep backwards compatibility. This is a continuation of ae855bf48163ff64d94cfc34aff8e37abdb5518d and a preparation to have Java 9 module support. Change-Id: Ifbbfb97f60373d14256e62ae3122913bd17d5bbb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91930 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-02-16	GBUILD_TRACE, support for finding out where the build time is spent	Luboš Luňák
	See instructions in solenv/gbuild/Trace.mk . This generates a file than can be viewed e.g. in the Chromium tracing view. Change-Id: I5f90647c58ca729375525b6daed2d4918adc8188 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88754 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-02-04	tdf#117331 Merge jurt and unoil into ridl	Samuel Mehrbrodt
	jurt.jar and unoil.jar are kept as effectively empty jars, each with a Class-Path: ridl.jar in their meta-inf/manifest.mf, so that 3rd-party code loading them (with or without also loading ridl.jar) will still have access to their content. Conceptually, the UNOIDL entities in unoil.jar (corresponding to module offapi) are not part of the URE, but are now made available by URE's ridl.jar. This should probably not cause problems in practice. At least for now, we seal exactly those packages in ridl.jar that were originally sealed in jurt.jar. Ideally, all of ridl.jar could be sealed now, but that would be mildly incompatible, as it would prevent 3rd-party code from introducing additional UNOIDL entities in the relevant namespaces (even if that is something we do not want 3rd-party code to do anyway). However, some JunitTest_jurt_* define classes in those sealed packages. In the past they got away with that by using gb_JunitTest_use_jar_classset,,jurt. Instead they now need to gb_JunitTest_use_jar_classset,,ridl and drop the gb_JunitTest_use_jar,,ridl. But the former only makes available the classes that are specified in ridljar/Jar_ridl.mk with gb_Jar_add_sourcefiles, not the UNOIDL entities specified via gb_Jar_add_packagedirs. But the tests need the udkapi UNOIDL entities, so introduce gb_JunitTest_add_classpath to let the tests get them explicitly. (Curiously, JunitTest_jurt_uno and JnitTest_jurt_util use gb_JunitTest_use_jar_classset,,jurt but don't seem to acutally need it; lets leave that for a follow-up clean up.) As a follow-up clean up, relevant files could be moved from jurt/ to ridljar/. Change-Id: I836f4e7bb47fb41f1306e3f223da90dba988eb9a Co-authored-by: Stephan Bergmann <sbergman@redhat.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/84946 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-04-16	Use https instead of http	Gulsah Kose
	Use "https://cgit.freedesktop.org/libreoffice/core" instead of "http://cgit.freedesktop.org/libreoffice/core" Change-Id: Ic7248eeb2a9452da7236eeee08414a77714dd234 Signed-off-by: Gulsah Kose <gulsah.1004@gmail.com> Reviewed-on: https://gerrit.libreoffice.org/52926 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2017-11-24	tdf#113787: always require version file with config for CLI assemblies	Michael Stahl
	The CliUnoApi_oootypes does not use the same version file as everything else, so pass that in as a parameter.
2017-08-16	tdf#108709 cli_ure,unoil: bump CLI assembly versions for 5.4	Michael Stahl
	perl cli_ure/source/scripts/increment_version.pl cli_ure/version/version.txt cli_ure/version/incversions.txt temp.txt && mv temp.txt cli_ure/version/version.txt perl cli_ure/source/scripts/increment_version.pl unoil/climaker/version.txt unoil/climaker/incversions.txt temp.txt && mv temp.txt unoil/climaker/version.txt Change-Id: Iaea028fc345d090317f7ebf128b683b4643a1093
2017-08-16	cli_ure,unoil: always increment all CLI assembly version numbers	Michael Stahl
	There is a increment_version.pl, which uses the incversions.txt to increment the CLI version numbers. But it first checks that there are new published UNO types, and exits if there are none. Not sure where the input for that is supposed to come from. But the OOo docs claim that all version numbers have to be incresed for every release to work around some MSI issue, so change the script to do that and add an incversion.txt in unoil too. http://www.openoffice.org/udk/common/man/spec/assemblyversioning.html https://support.microsoft.com/en-us/help/905238/an-assembly-in-the-global-assembly-cache-or-sxs-is-missing-after-you-p Change-Id: I6190b53d1a3ff00b9fe014f86f7ec8cddef9904e
2015-12-03	Add build toolchain to upload LibreOffice API to Maven Central	David Ostrovsky
	Set up the toolchain to create sources and javadocs artifacts in addition to JARs created during the build. Use Buck build tool for that: [1]. This is a fork of Google's build tool Blaze, created by Xooglers at Facebook. This build tool (like Blaze itself) uses Python to write build files. Add needed tools and build files to install LibreOffice API artifacts to local Maven repository or deploy them to Maven Central. To build all needed artifacts LibreOffice must be built regularly with GNU make first. To build the rest of the API (sources and javadocs): $> buck build api To replace version number with upcoming release version: $> solenv/bin/version.py 5.1.0 To install the API to local Maven repository: $> buck build api_install To deploy the API to Maven Central: $> buck build api_deploy Detailed documentation is added to document the prerequisites and the workflow to upload LibreOffice API to Maven Central. * [1] https://buckbuild.com Change-Id: Ibdd552a01110836703bc069abe829b9921491cac Reviewed-on: https://gerrit.libreoffice.org/20343 Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2015-12-01	Expose metadata to deploy LibreOffice artifacts on Maven Central	David Ostrovsky
	As outlined in the requirements to deploy the artifacts on Maven Central, the metdata must be provided: * Project Name, Description and URL * License Information * Developer Information * SCM Information [1] http://central.sonatype.org/pages/requirements.html Change-Id: I0bcd19a22d0e1a48f0faec0b414f816f7da5b318 Reviewed-on: https://gerrit.libreoffice.org/20315 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>