[tools-dev] Java properties L10N support
Hi folks, Short version: The L10N process now support java properties. If you want exclude your properties file please mark it at the beginning of the file with a # x-no-translate . If you want your java properties files to be merged during the build set the PACKAGE variable and add all your properties files into the L10NPROPERTYFILES variable in the makefile. Long Version: There is now java properties support starting from DEV300 m84 (#i112091#). The L10N process will now take care of everything in the sources named *.properties thus if you want to exclude your properties file then please add a marker # x-no-translate direct below of the the copyright text. The parser stops as soon as this marker is found. I did that already for all properties files found so far in DEV300 m82 (#i112445#) . If you introduce a new one please add such a marker if you want to exclude it. Side note, just properties files that are checked in are taken , nothing in the output trees nor in any zips. If you want your files be localized e.g. for extensions there is makefile support (#i112394#): L10NPROPERTYFILES:=$(CLASSDIR)/$(PACKAGE)/myfile.properties Please note that it is mandatory that the properties files must reside beside the makefile.mk, to set the $(PACKAGE) variable and they have to go into $(CLASSDIR). Ause might generalize this in the future if there is a need. e.g. PACKAGE = com$/sun$/star$/report$/function$/metadata L10NPROPERTYFILES := $(CLASSDIR)$/$(PACKAGE)$/category.properties - unxlngx6.pro/class/com/sun/star/report/function/metadata/category.properties see the example for further details. There is some kind of magic in the parser in the way how it detect and name the output files. We basically have two different kinds of java properties. The real ones and those that only look like but that are not due to historical reasons Those that the parser will recognize as real ones are ( case sensitive! ): mypropfile_en_us.properties mypropfile.properties Those will appear localized in the output tree like mypropfile_de.properties mypropfile_pt.properties mypropfile_pt_br.properties The other ones are created by the basic dialog editor and they enforce a different nameing scheme: mypropfile_en_US.properties Those will appear localized in the output tree like: mypropfile_de_DE.properties mypropfile_pt_PT.properties mypropfile_pt_BR.properties I propose to create all real new java property using the form without any language code, e.g. mypropfile.properties for en-US RE dislikes to see: - Please don't check in any translated files like mypropfile_de.properties, mypropfile_fr.properties etc - Please don't check in duplicated properties files ( e.g. both mypropfile.properties and mypropfile_en_us.properties) - Please don't check in any strange names like my properties file.properties or mypropfile.pRoPeRtIeS or mypropfile_EN_us.properties etc - Please don't forget to mark any new files that end with .properties that should not be part of the L10N process Example session: pwd reportbuilder/java/com/sun/star/report/function/metadata echo $WITH_LANG de pt pt-BR cat makefile.mk [..] PRJ= ..$/..$/..$/..$/..$/..$/.. PRJNAME = reportbuilder TARGET= rpt_java_css_metadata PACKAGE = com$/sun$/star$/report$/function$/metadata # --- Settings - .INCLUDE: settings.mk #- compile .java files - [..] L10NPROPERTYFILES := $(CLASSDIR)$/$(PACKAGE)$/category.properties \ $(CLASSDIR)$/$(PACKAGE)$/Author-Function_en_US.properties \ $(CLASSDIR)$/$(PACKAGE)$/Title-Function_en_us.properties # --- Targets -- .INCLUDE : target.mk dmake Writing to: ../../../../../../../unxlngx6.pro/class/com/sun/star/report/function/metadata/Author-Function_de_DE.properties ../../../../../../../unxlngx6.pro/class/com/sun/star/report/function/metadata/Author-Function_pt_BR.properties ../../../../../../../unxlngx6.pro/class/com/sun/star/report/function/metadata/Author-Function_pt_PT.properties ../../../../../../../unxlngx6.pro/class/com/sun/star/report/function/metadata/Author-Function_en_US.properties ../../../../../../../unxlngx6.pro/class/com/sun/star/report/function/metadata/Author-Function_fr_FR.properties ../../../../../../../unxlngx6.pro/class/com/sun/star/report/function/metadata/Title-Function_de.properties ../../../../../../../unxlngx6.pro/class/com/sun/star/report/function/metadata/Title-Function_pt_br.properties ../../../../../../../unxlngx6.pro/class/com/sun/star/report/function/metadata/Title-Function_pt.properties ../../../../../../../unxlngx6.pro/class/com/sun/star/report/function/metadata/Title-Function_en_us.properties ../../../../../../../unxlngx6.pro/class/com/sun/star/report/function/metadata/Title-Function_fr.properties
[tools-dev] Error building OOo-3.2.1 on sfx2 module
Hi all, I'm finding this problem building OOo DEV300_m81 on WinXP. Entering /cygdrive/c/DEV300_m81/sfx2/workben/custompanel Compiling: sfx2/wntmsci12.pro/misc/custompanel.uno_version.c dmake: Error: -- `/cygdrive/c/DEV300_m81/solver/300/wntmsci12.pro/bin/osl/licen se_en-US.txt' not found, and can't be made 1 module(s): sfx2 need(s) to be rebuilt If I copy such license file inside the directory the build process continues without problem. The same happens for the license_it.txt file. Davide signature.asc Description: OpenPGP digital signature
Re: [tools-dev] EIS CWS AllowedRelease/AllowedTaskTargets Problems
On 22.06.2010 16:52, Philipp Lohmann wrote: Hi, On 6/22/10 2:49 PM, Bernd Eilers wrote: Mathias Bauer wrote: That's exactly what Stephan said: bureaucratic humbug. Well I know we do have some members in an implement_as_you_want_when_you_want_and_dont_care_about_qa-needs_roadmaps_or_documentation camp but I didn´t really expect you two to be in there ;-) Name calling aside: what about issues concerning extensions ? Right now I have to move the target from the correct milestone 1 of an extension to 3.3 or some such to satisfy EIS. Which is kind of bogus. However the CWS should be 3.4 or some such since that marks into which repository code line the CWS will get integrated. one of the objective of extensions was to have an Office independent release schedule. This automatically leads to an own issue tracking and own repository, from my point of view we even can have a simplified development process, since all the cws handling was introduced not to break office code. So I would leave it to the developers of the extension whether they want to have cws or another model. Sane extensions can't break office code ! Extensions, please break out of the Office workspace, Just my 2 cents, pl +2 cent, Martin - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] EIS CWS AllowedRelease/AllowedTaskTargets Problems
On 23.06.2010 00:13, Mathias Bauer wrote: On 22.06.2010 14:49, Bernd Eilers wrote: Mathias Bauer wrote: Hi, Hi, the right solution would be to remove the check. A target milestone is a hint when a particular should be fixed or is planned to be fixed. The same is true for a CWS. If a developers decided to fix an issue earlier or finish a CWS earlier, why should that be marked as failed? Because the data of the issue doesn´t match the data of the CWS and we have an inconsistent state in the tools that document what we are doing. Where is the point of not wanting to also change the issue data if the decision when to fix the issue did change. Why do you want to refuse to document that by changing the issue data. The failed status in this case is just a hint to the developer that there are issues on his CWS which either need to be fixed on another CWS which is based on another codeline or which need to be adjusted to be fixed on another target which might eventually also need an agreement about that with other stakeholders involved. That's exactly what Stephan said: bureaucratic humbug. Well I know we do have some members in an implement_as_you_want_when_you_want_and_dont_care_about_qa-needs_roadmaps_or_documentation camp but I didn´t really expect you two to be in there ;-) That's complete nonsense. Setting a target to an issue or CWS can be done short before or even after a CWS is integrated. If you ever had to change the targets of issues or CWS just because you had set them to the allowed target but then - when the CWS did not make it into the release - had to change it again, you might understand why I think that is bureaucratic humbug. The target release of an issue or CWS *before* it gets integrated is unrelated to what is documented or even to what exactly ends in the release. In a train model you never know the time of arrival exactly before the train really arrives. So a target release is just a declaration of what is aimed for, nothing else. Why else are we retargetting so much issues each and every release? From my experience from the 10 past years we should only set the target milestone when the code actually get integrated. From my point of view we should only set target milestones for regression issues and stoppers only. Nevertheless I think a cws should only be integrated if all issues have the right milestone set, so that we can track with Issuezilla what actually got into the release. Making this random will lead that the target milestone will randomly set. I will set the nomination right anyhow for 3.4 for release management only, so these people will be the only one to fight their bureaucratic humbug theirself :-). Martin Ciao, Mathias - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
