[dev] localization moved into a own repository

[Ivo Hinkelmann]

Hi,

with the integration of the cws l10nmove the way change how to make a 
localized build. The reason for the change is that we want that the 
contl10n process integrates new localization every milestone. We moved 
the localization into a own repository, master_l10n / cws_l10n, to 
reduce the growing of the main repository caused by the localization. As 
we have about 100 languages a single changed string causes 100 changes 
in the l10n module. Most developers don't need the localization thus it 
does not make sense to download/clone all the changesets from the l10n 
process.


In case you are doing en-US only builds only, e.g. while developing then
nothing will change for you.

If you want a localized master build you need to do this:

- clone the OOo repository ( of cause! )
- clone the l10n repository
- copy a so called source_config file beside your both repositories
- use configure --with-lang=de,cs,xy as usual


- clone the OOo repository
> hg clone http://hg.services.openoffice.org/master/DEV300 ooo

- clone the l10n repository
> hg clone http://hg.services.openoffice.org/master_l10n/DEV300 l10n
please name it l10n as we refer to that in the makefile system

- copy a so called source_config file beside your both repositories
This source_config file is used to introduce both repositories to 
build.pl and possible further tools. For some more info about 
source_config please read this:

http://wiki.services.openoffice.org/wiki/Source_config

> ls
l10n  ooosource_config
> cat source_config
[repositories]
ooo=active
l10n=active

- use configure --with-lang=de,cs,xy as usual
> cd ooo
> ./configure --with-lang=de [...]
> ./bootstrap
> source LinuxX86-64Env.Set
> echo $gb_REPOS
/net/so-cwsserv03/export/cws/l10nmove/ooo
/net/so-cwsserv03/export/cws/l10nmove/l10n

The gb_REPOS environment variable introduce the repositories to the gnu
build system.

Just for the case anyone uses the cws fetch command, I added a new
switch "-r" for additional repositories. Add this to your .cwsrc file:
L10N_HG_REMOTE_SOURCE=http://hg.services.openoffice.org/

Read here for some more background about the .cwsrc file:
http://wiki.services.openoffice.org/wiki/Mercurial/Cws#Configuring_cws_fetch

> cws fetch -c l10nmove -r l10n l10nmove

This will clone the ooo and l10n repository of your cws ( e.g. l10nmove )

Cheers,
Ivo
--

To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: sy...@openoffice.org with Subject: help

[dev] Java properties L10N support

[Ivo Hinkelmann]

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
../../../../../../../unxlngx6.pro/class/com/sun/star/report/function/metadata

Re: [dev] Errors using gsicheck on DEV300_m60

[Ivo Hinkelmann]

Hi,

please use :

http://ftp.uni-erlangen.de/pub/mirrors/openoffice/extended/ooomisc/sdf/DEV300_m60_2009-10-02_15-56-20.sdf.bz2

Sorry,
Ivo

Kristján Bjarni Guðmundsson schrieb:

Does this mean that the en-US.sdf file is not tested with gsicheck before
being released?
Wouldn't it be a good idea to do that to prevent these problems in the
future?

Now the problem I am having is that I am using Translate Toolkit with po2oo
and because the en-US.sdf is
used as the template input the resulting localize.sdf file is also buggy.

Is a  fixed en-US.sdf for DEV300_m60 available somewhere to download?

- - - - - - - - - Áframsendur póstur - - - - - - - - - -

From: Ruediger Timm 
To: dev@openoffice.org
Date: Wed, 30 Sep 2009 08:55:52 +0200
Subject: Re: [dev] Errors using gsicheck on DEV300_m60
On 09/30/09 00:12, Kristján Bjarni Guðmundsson wrote:


I tried running gsicheck on the en-US.sdf file for the DEV300_m60 release
and I am getting these errors:

Error: File format, Line 72253, UniqueID uui/source\ids.src/title/)///:
Source Language entry double. Treating as Translation.
Error: File format, Line 72254, UniqueID uui/source\ids.src/title/)///:
Source Language entry double. Treating as Translation.
Error: File format, Line 72254, UniqueID uui/source\ids.src/title/)///:
Translation Language entry double. Checking both.
Error: File format, Line 72255, UniqueID uui/source\ids.src/title/)///:
Source Language entry double. Treating as Translation.
Error: File format, Line 72255, UniqueID uui/source\ids.src/title/)///:
Translation Language entry double. Checking both.
Error: File format, Line 72255, UniqueID uui/source\ids.src/title/)///:
Translation Language entry double. Checking both.

I there a newer version of gsicheck that I am supposed to use with the
DEV300_m60 version?



There is a syntax bug in file uui/source/ids.src causing this buggy lines
in the sdf file. So, gsicheck is correct, the sdf file isn't. The bug is
fixed in revision 276471 for upcoming DEV300 m61 and in revision 276464 for
branch OOO320.

Rüdiger






-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

[dev] Re: [l10n-dev] specs for Migration analysis module in 3.2

[Ivo Hinkelmann]

Hi Sophie,

d...@openoffice.org brought that into the source code with cws paw06 . 
Please ask him for further info.


Cheers,
Ivo

Sophie wrote:

Hi all,

(added d...@l10n in CC so the l10n teams are aware)

For the next 3.2 version, we have a UI localization directory 
migrationanalysis which have :

src/driver_docs.po and src/wizard.po files.
Where can I find the specs for what seems to be Documentation Analysis 
Wizard and Professional Analysis Wizard?


I didn't find anything about it here
http://development.openoffice.org/releases/DEV300_m54_snapshot.html

Thanks in advance
Kind regards
Sophie

-
To unsubscribe, e-mail: dev-unsubscr...@l10n.openoffice.org
For additional commands, e-mail: dev-h...@l10n.openoffice.org




-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

[dev] DEV300 m53 missing patch in module moz

[Ivo Hinkelmann]

Hi all,

the file moz/seamonkey-source-1.1.14.patch from cws moz2seamonkey01 is 
somehow missing in the m53 milestone . The patch has been commited on 
trunk for the m54. In case your build dies in moz please update this file.


Cheers,
Ivo

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

Re: [dev] Re: [l10n-dev] Localisation moved into own module

[Ivo Hinkelmann]

Hi,

Frank Schönheit - Sun Microsystems Germany schrieb:

Hi Ivo,


I guess that for building a language pack the OOo source tree would not
be needed anymore, except maybe a few modules, is still a wish for the
far future?
MBA had the idea to move also all resource source files into a own 
module but we first need to discuss this a bit further 


Don't think this would be a good idea. I'd hate to deal with / build Yet
Another 100MB monster if I just want to change a resource string in a
project of mine.


it is the question of the point of view. People who build languagepacks 
on a regular basis benefit a lot from this change. They don't have to 
check out the whole giant source tree, build the giant source tree etc 
... Would this hurt so much ?


Cheers,
Ivo

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

Re: [dev] Re: [l10n-dev] Localisation moved into own module

[Ivo Hinkelmann]

Hi Rene,

Rene Engelhard wrote:

Hi,

Thorsten Ziehm wrote:

the goal to to build and deliver language packs without any
dependencies. This CWS is the first step. There are still some steps
open. But as I heard by Ivo, when this CWs is ready you can you can
build the localization without any obj's / libs / whatever. But the


[snip]


So there will be a benefit. ;-)


Though only a small one... :)


you can build language packs without the need of building all the objs 
of svx, sw , binfilter and friends ... thats is already a bigger 
benefit, esp. if you don't own a 16 core machine ;)


Cheers,
Ivo



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

Re: [dev] Re: [l10n-dev] Localisation moved into own module

[Ivo Hinkelmann]

Hi Eike,

Eike Rathke wrote:


I guess that for building a language pack the OOo source tree would not
be needed anymore, except maybe a few modules, is still a wish for the
far future?


MBA had the idea to move also all resource source files into a own 
module but we first need to discuss this a bit further 


Cheers,
Ivo



  Eike




-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

[dev] Localisation moved into own module

[Ivo Hinkelmann]

Hi,


the DEV300 m51 milestones contains the cws l10ncleanup04 that moves all 
the translations that are spread over the office code to the new module 
"l10n".


The structure of this l10n module is like this:

l10n/
l10n/source/
l10n/source/af
l10n/source/af/localize.sdf
l10n/source/ar/localize.sdf
[...]

thus you only have one file per language. The localize.pl tool had been 
modified so it will merge the big file there. If you are a translator 
and/or want to build a instset with updated localisations then you can 
also just move your new modified file over it instead of merging it with 
localize -m 


A build in this l10n directory will spread the big files again into 
small mixed ones in the output tree. This step is needed so the l10n 
tools don't need to parse the huge files again and again:


cd l10n && build
[...]
ls

l10n/
l10n/unxlngi6.pro/
l10n/unxlngi6.pro/misc/
l10n/unxlngi6.pro/misc/sdf/
l10n/unxlngi6.pro/misc/sdf/accessibility/
l10n/unxlngi6.pro/misc/sdf/accessibility/source/
l10n/unxlngi6.pro/misc/sdf/accessibility/source/helper
l10n/unxlngi6.pro/misc/sdf/accessibility/source/helper/localize.sdf
l10n/unxlngi6.pro/misc/sdf/avmedia/
l10n/unxlngi6.pro/misc/sdf/avmedia/source/
l10n/unxlngi6.pro/misc/sdf/avmedia/source/framework
l10n/unxlngi6.pro/misc/sdf/avmedia/source/framework/localize.sdf
l10n/unxlngi6.pro/misc/sdf/avmedia/source/viewer
l10n/unxlngi6.pro/misc/sdf/avmedia/source/viewer/localize.sdf
[...]

NOTE: As the cws moved more then 2 GB in the repository your next cws 
rebase might be quite slow! Please don't blame Heiner for that and don't 
send any angry mails to him ;)


Cheers,
Ivo


Crossposting to d...@openoffice and d...@l10n.openoffice

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org

Re: [dev] fixing a translation ?

[Ivo Hinkelmann]

Hi Caolan,

Caolan McNamara wrote:


So just to be clear, the code gets synced to from the translation
database which is the master copy, so when e.g. someone provides a new
translation .sdf it goes into the translation database and then into the
code, and that's for *all* translations, not just translations done by
Hamburg itself, e.g. this is the same for de as well as e.g. dz


yes thats correct.



And what about the en-US strings, the ones in the .src files which don't
appear in localize.sdf, if there was a typo in one of those. Are changes
to those ones done by entering into the translation database and then
mirrored into the source or is the scheme of things...


If there is a typo you can just change that in the src file and check 
in! Every milestone all new or changed en-US strings from the master are 
imported into that database. We do that to track those strings.




master en-US string in .src files; check into source
everything else; enter into translation database -> sync into source


Yeah!



C.


Cheers,
Ivo

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] fixing a translation ?

[Ivo Hinkelmann]

Hi Caolan,

please file an issue to petr_dudacek, paste the wrong and the fixed sdf 
line into that issue. He will fix that in the translation database which 
will be synced from time to time with the code line.


Cheers,
Ivo

Caolan McNamara wrote:

Just a very simple question. If there is a misspelling/mistake in a
translation e.g. the same text has been used for "insert column" and
"delete column" in a particular language and a replacement string has
been provided. What's the way to fix it, is it simply to commit the
change to the appropriate localize.sdf or does that lead to the fix
getting clobbered by some other out-of-tree set of translation data ?

C.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[dev] build breaker in SRC680 m238

[Ivo Hinkelmann]

Hi,

there is still one build breaker in m238. Please update the file 
sw/source/core/fields/docufld.cxx to revision 1.48 



cvs diff -r1.46 -r1.48 docufld.cxx
CVS wrapper -- version: 1.101
Index: docufld.cxx
===
RCS file: /cvs/sw/sw/source/core/fields/docufld.cxx,v
retrieving revision 1.46
retrieving revision 1.48
diff -r1.46 -r1.48
7c7
<  *  $Revision: 1.46 $
---
>  *  $Revision: 1.48 $
9c9
<  *  last change: $Author: ihi $ $Date: 2007/11/26 15:29:04 $
---
>  *  last change: $Author: ihi $ $Date: 2007/12/03 14:25:25 $
1200a1201
> break;
1205d1205
<   break;

Cheers,
Ivo

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[dev] German is no longer required in resource files

[Ivo Hinkelmann - Sun Germany -]

Hi,

the cws mergede01 moved all German language strings from the resource 
files to the localize.sdf snippets. Beginning with the m210 only the 
English source strings are required in the resource files. Please resync 
your cws onto the milestone m210 and remove all in your cws new 
introduced German entries. The German strings will be translated by our 
translation process.


Soon we will introduce a new mechanism to add so called recommend files. 
You can use those files to add translation recommendations in any language.


Cheers,
Ivo

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] German *.src / *_tmpl.hrc entries now UTF8 and a flag file in /prj introduced

[Ivo Hinkelmann]

Hi Frank,

Frank Schönheit - Sun Microsystems Germany wrote:

Hi Ivo,



Okay, what do I have to do to repair this file?


/bin/echo -ne "\357\273\277" > mytmp ; cat sbabrw.src >> mytmp ; mv 
sbabrw.src sbabrw.src.old ; mv mytmp sbabrw.src


this command does not change the encoding ( use recode for that ), but 
only add those 3 Byte UTF8 marker infront of the file




Please use "echo" from /bin and not the shell build-in one.



Okay, and here the solution for MSDEV users:
  File|Save As|Save with encoding|Unicode (UTF-8, with signature)

I meanwhile found that dbaccess/source/ui/browser/sbabrw.src did contain
UTF-8 encoded German strings, but *not* the signature byte (thus the
umlauts were improperly displayed). In the other hand,


see above


dbaccess/source/ui/dlg/dbadmin.src did not contain UTF-8 encoded german
strings at all, neither with nor without signature byte. Instead, the
umlauts seemed to exist in the old encoding. /me is confused.


this is a bug! As the cws has not been integrated in the timeframe I 
expected, I was forced to resync several times. Thus this is a merge 
conflict. Please save as UTF8 and search / replace broken "umlauts" if 
needed.


Cheers,
Ivo

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] German *.src / *_tmpl.hrc entries now UTF8 and a flag file in /prj introduced

[Ivo Hinkelmann]

Hi Mathias,

Mathias Bauer wrote:

Ivo Hinkelmann wrote:


Hi Frank,

Frank Schönheit - Sun Microsystems Germany wrote:



Today, the process for new strings involves specifying both the germany
and the english string in the spec document, and writing them into the
.src (done by the developer). If the german string is not to be entered
at source-level anymore, how would this work? Would only the english
string be specified, and the german version is part of the usual
translation process?


Yes why not! To handle German as a usual translation language has a lot 
of benefits:


- In a international open source project having German source language 
strings looks a bit strange to me ( and confuse non German speaking 
developers a lot )


- There is only one "truth" . Imagine you have two strings where en-US 
and de translation does not match. What is the "real" one ? We already 
had such cases.



Usually the german text is the "real one" because most people creating


but this may not always be the case. For (fictive) example:

ModalDialog DLG_GREEN_LINE
{
HelpID = HID_YELLOW_LINE ;
OutputSize = TRUE ;
SVLook = TRUE ;
Size = MAP_APPFONT ( 239 , 68 ) ;
/* XYZ: 1.6.1998: Die Linie ist jetzt orange! */
Text [ en-US ] = "Black line" ;
Text [ de ]= "Grüne Linie" ;
Moveable = TRUE ;


and the developer has left the company 4 years ago...


the UI specs are native german speakers and we usually need a native
english speaker to create useful english texts.

So IMHO we still need the german strings in the specifications. The only
alternative is to have native english speakers writing the specification
part dealing with the strings, but that is unlikely to happen.


Ok, I see it is better to have the German strings in the spec. My aim is 
to get that string straight into the database and to get the resource 
files plain en-US. If there exits tooling like a web database interface 
 that should not hamper the specification process too much.


Cheers,
Ivo



This change is good for building the code but it is not well prepared
IMHO because it creates problems for the specification process.

Ciao,
Mathias



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] German *.src / *_tmpl.hrc entries now UTF8 and a flag file in /prj introduced

[Ivo Hinkelmann]

Hi Frank,

Frank Schönheit - Sun Microsystems Germany wrote:

Hi Ivo,



(and no, neither my IDE's editor nor my fallback editor (TextPad)
currently seem to recognize UTF-8 :( )


I don't know what IDE you use. My msdev opens resources files well.



Hmm, I opened dbaccess/source/ui/browser/sbabrw.src from src.m133, and
msdev showed me only garbage instead of umlauts.

Investigating this, it seems I accidentally hit one of the few files
which does not have the "Byte order marker", and thus is broken. Other
files with umlauts open fine in msdev (and, well, also in my fallback
text editor :).

Okay, what do I have to do to repair this file?


/bin/echo -ne "\357\273\277" > mytmp ; cat sbabrw.src >> mytmp ; mv 
sbabrw.src sbabrw.src.old ; mv mytmp sbabrw.src


Please use "echo" from /bin and not the shell build-in one.

Cheers,
Ivo

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] German *.src / *_tmpl.hrc entries now UTF8 and a flag file in /prj introduced

[Ivo Hinkelmann]

Hi Frank,

Frank Schönheit - Sun Microsystems Germany wrote:

Hi Ivo,




Today, the process for new strings involves specifying both the germany
and the english string in the spec document, and writing them into the
.src (done by the developer). If the german string is not to be entered
at source-level anymore, how would this work? Would only the english
string be specified, and the german version is part of the usual
translation process?


Yes why not! To handle German as a usual translation language has a lot 
of benefits:

...



Sure, I don't object this. Just saying that our current process requires
german strings to be specified and reviewed (linguistic-wise) even
before implementation starts (in theory), and that the developer is
responsible for maintaining the german strings in the resource files.


Yes I know, the process have to be modified if we decide to do that...



If german becomes another traslation language (I'd be fine with this),
there are more consequences than only technical ones. Somebody needs to
allocate the resources for the german translation, at least. OR, german


second option is better imho


strings are "created" as they're today, and we give developers technical
means to push them into a translation database.


I don't think hacking the German strings into the database and not into 
the resource is not that complicated. I could imagine that the spec 
writer enter the string into the database.



I had hope you already solved those problems, that's why I was asking
for how the solutions look like :)


I don't solve any problems yet, just ask if this could be an option or not.



Ciao
Frank



Cheers,
Ivo

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] German *.src / *_tmpl.hrc entries now UTF8 and a flag file in /prj introduced

[Ivo Hinkelmann]

Hi Frank,

Frank Schönheit - Sun Microsystems Germany wrote:

Hi Eike,



conflicts during cws resync caused by this change. In this case convert
your new / changed strings to UTF8.


Dumb question: how do I do this?


Dull answer: use an editor ;-)
...



Well, what I like about the concept of an "Integrated Development
Environment (IDE)" is the word "integrated" 

(and no, neither my IDE's editor nor my fallback editor (TextPad)
currently seem to recognize UTF-8 :( )



I don't know what IDE you use. My msdev opens resources files well.


Let me rephrase this: When such a change was first discussed, there was
the idea to use files which somehow indicate they're UTF-8, IIRC with
some signature bytes at the beginning, something like this. It was said
that this would enable more editors to properly handle those files. What
became of this idea?


Every editors writes those "Byte order marker" while saving the document 
in UTF8. Or lets say nearly all ;)





I'm not really objecting the change as such, I suppose it solves a lot
of problems for people L10N'ing OOo. However, to me it seems to create
new problems for other people (well, developers). This is okay in
general, provided that the sum of hassles decreased (it's bad luck then
that now some of us developers have the hassle to do additional
conversion steps or change to another editor). However, it would have
been nice to address those new problems before doing the change, IMO.


As 95% of all editors are able to read/write UTF8 I didn't saw any 
reason to do so.




Anyway. If German is removed from the files, the problems would vanish.
However, I'm still waiting for the answer how this interacts with our
current feature implementation process, which requires us developers to
specify and implement the German strings from the beginning.



For other editors, if they're not able to cope with utf-8, you may
always type and save your text in latin1 respectively cp1252 and use the
``recode'' utility to convert, e.g. ``recode latin1..utf-8 filename''
respectively ``recode cp1252..utf-8 filename''. However, I'd suggest
switching editor in this case ;-)



"recode" is not known in my development environment ...
(yeah, I can probably obtain it somewhere. Again: Would have been nice
to address those issues *beforehand*.)

Ciao
Frank



Cheers,
Ivo

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] German *.src / *_tmpl.hrc entries now UTF8 and a flag file in /prj introduced

[Ivo Hinkelmann]

Hi Frank,

Frank Schönheit - Sun Microsystems Germany wrote:

Hi Ivo,



- The German entries in resource files ( *.src / *_tmpl.hrc ) have been
converted to UTF8, thus there is no more different handling of German
and English US entries like before ( MS1252 vs. UTF8 ). You may get
conflicts during cws resync caused by this change. In this case convert
your new / changed strings to UTF8.



Dumb question: how do I do this? I darkly remember that a while ago, we
discussed whether all our editors in engineering are capable of encoding
in UTF-8 automatically (if some signature byte at the beginning of the
file requires this), but not sure what was the outcome.


Take care that _your_ favourite editor writes UTF8, I don't know what 
"all our editors in engineering" are.




In other words:
If, in the future, I want to enter arbitrary germany text containing an,
say, ü, into an arbitrary .src file - what do I need to care for?



Open that file for example in firefox, set View->Character 
Encoding->Unicode (UTF8) and if you still see "ü" -> ok , if you see "?" 
, "[EMAIL PROTECTED]" , or similar -> something is wrong





- There is a new flag file /prj/l10n which indicates the
existence of German localisation. If this file exits, all resource files
( *.src / *_tmpl.hrc / *.xcu / *.xrm / *.xrb / *.ulf ) in the whole
module source tree contains both languges, German and English US. If
that file lacks, only English US is present and the German translations
are located, like all other translations, in the localize.sdf files in
each directory. If you introduce a new module please add such a file
into your /prj/ directory if nessesary!



I suppose this requirement will be documented somewhere? Just kidding ...


yes, in #i49922# ;)





Any objections to treat German as a usual translation language and
remove the German entries complete from all resource files in the future?



Today, the process for new strings involves specifying both the germany
and the english string in the spec document, and writing them into the
.src (done by the developer). If the german string is not to be entered
at source-level anymore, how would this work? Would only the english
string be specified, and the german version is part of the usual
translation process?


Yes why not! To handle German as a usual translation language has a lot 
of benefits:


- In a international open source project having German source language 
strings looks a bit strange to me ( and confuse non German speaking 
developers a lot )


- There is only one "truth" . Imagine you have two strings where en-US 
and de translation does not match. What is the "real" one ? We already 
had such cases.


- Consistency, there is no mix with resources having en-US only or en-US 
+ de string ( #i49922# )




Thanks & Ciao
Frank



Cheers,
Ivo

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[dev] German *.src / *_tmpl.hrc entries now UTF8 and a flag file in /prj introduced

[Ivo Hinkelmann]

Hi,

the cws "encup" integrated into the milestone m131 introduce two l10n 
related changes:


- The German entries in resource files ( *.src / *_tmpl.hrc ) have been 
converted to UTF8, thus there is no more different handling of German 
and English US entries like before ( MS1252 vs. UTF8 ). You may get 
conflicts during cws resync caused by this change. In this case convert 
your new / changed strings to UTF8.


- There is a new flag file /prj/l10n which indicates the 
existence of German localisation. If this file exits, all resource files 
( *.src / *_tmpl.hrc / *.xcu / *.xrm / *.xrb / *.ulf ) in the whole 
module source tree contains both languges, German and English US. If 
that file lacks, only English US is present and the German translations 
are located, like all other translations, in the localize.sdf files in 
each directory. If you introduce a new module please add such a file 
into your /prj/ directory if nessesary!


Any objections to treat German as a usual translation language and 
remove the German entries complete from all resource files in the future?


Cheers,
Ivo

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Localized build for a particular language

[Ivo Hinkelmann]

Hi Peam,

you want build a Dzonkha office in English ??? Why not build a multi 
installation office, where you can switch the gui between "dz" and "en-US" ?


cd /instsetoo_native
build openoffice_dz_en-US

Cheers,
Ivo

Pema Geyleg wrote:

Dear all,

I would like to build a localized build with-lang="dz" but with the 
English ineterface.
  Could some one please tell me which files needs to be modified in 
ooSRC680.
   The Bhutanese team are in the process of translating Open office user 
interfaces to Dzongkha.Till date there had not been technical 
translation work and as such we need to coin new terms and consult a lot 
which hinders in the pace of translation work. However, technically open 
office supports Dzongkha now and the teaching medium in school here at 
Bhutan is English language. We would like to use open office with the 
english interfaces for the time being until we complete the translation 
work.



Many Thanks
Pema Geyleg
+++
Get a free DrukNet e-mail account and stay in touch
http://www.druknet.bt   
-

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Vietnamese UI during SETUP OOo was broken

[Ivo Hinkelmann]

Hi ,

add the line

vi 0 1066

to your setup_native/source/win32/msi-encodinglist.txt and rebuild.

Cheers,
Ivo

Vien Du Tran wrote:

Hi all,

I built OOo 1.9.m91 under Windows in cygwin and 4nt environments with 
Vietnamese language. And I was successful.


Vietnamese UI in OpenOffice.org applications is OK.
BUT Vietnamese UI during SETUP OOo was broken.

To display Vietnamese UI during SETUP OOo, I used UTF-8 character set and 
translated to Vietnamese in project "instsetoo_native".


Please tell me how to solve this problem.
Thank you very much!

[EMAIL PROTECTED] 


Start your day with Yahoo! - make it your home page 






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] localize patch for openoffice.org2

[Ivo Hinkelmann]

Hi Stanley,

thanks for the hint but please file an issue to 'ihi' and attach you
diff there instead of sending binary data to this mailing list.

Thanks,
Ivo

stanley peng wrote:
> Hi rene and ooo maintainer,
> 
> Here is a patch for openoffice.org2, which fixed some error of
> localizations.
> 
> The original source forgets to put a dbl-quotes beside OOO_VENDOR and
> OOO_LICENSE vars in some language, such as zh-CN and it.
> 
> Thx.
> 
> --
> Stanley Peng
> [EMAIL PROTECTED]
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] How to convert heplcontent file

[Ivo Hinkelmann]

Hi Didier ,

there is no such converter. If you have luck there is no line end issue 
and you can use this online help in a windows build, but I am not sure 
if this works.


Please ask this kind of questions in the related mailing list [EMAIL PROTECTED] 
:

http://l10n.openoffice.org/servlets/SummarizeList?listName=dev

Cheers,
Ivo

[EMAIL PROTECTED] wrote:

Hi,

I have helpcontent_31_unix.tgz but i want to recompile for windows, howto 
convert to helpcontent_31_wnt.zip ?

Thanks
Regards
Didier


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]