Thanks, I am going through the steps again carefully to see if I missed anything. I think it could be a simple problem because I don't have much experience with unix.
Thanks & Regards, Huda On Tue, May 20, 2008 at 3:53 PM, Ivo Hinkelmann <[EMAIL PROTECTED]> wrote: > Hi , > > maybe this is a localize.pl issue. I always use a unix for merging the > strings. I will try the windows/Cygwin shell today > > > Cheers, > Ivo > > Huda Sarfraz wrote: > >> Hi, >> Thanks for the prompt replies, I have re-tried everything: >> >> - Ran gsicheck (downloaded from >> http://ooo.services.openoffice.org/gsicheck/windows_gsicheck_1.8.7.zip) >> on the file as follows and got no messages or logfile: gsicheck -c -l "" >> GSI_ur.sdf >> - I source winenv.set.sh before calling localize.pl as follows: *. >> winenv.set.sh* (I'm building on Windows, using Cygwin with the bash >> shell) >> - The SRC_ROOT variable in winenv.set.sh is: >> *SRC_ROOT="e:/OOH680_m12"*and this is correct >> - Access rights for the localize.sdf files seem to be ok, I can write to >> them and save manually, however, when I first entered a character (a), >> and >> closed and re-opened, the character appeared as a square (could not >> display >> properly), and when I repeated the process, it seemed to be alright. >> This >> happened with two different files. The encoding for the files is Unicode >> so >> I don't understand why this was happening. >> >> I am still not getting the translations in the localize.pl file. >> >> Could this be a problem with running the configure script with >> *--with-lang="ur"* instead of *--with-lang="ur-PK"*? >> I could not get it to build at all with ur-PK, but with ur, I get a build >> where the layout is RTL. >> >> Is there anything else that I could be doing wrong? >> >> Thanks & Regards, >> Huda >> >> >> On Fri, May 16, 2008 at 12:18 AM, Ivo Hinkelmann <[EMAIL PROTECTED]> >> wrote: >> >> forgot one .... do you ever run a gsicheck on your file? Are any errors >>> reported? >>> >>> >>> Ivo Hinkelmann wrote: >>> >>> Hi, >>>> >>>> do you sourced the LinuxX86Env.Set(.sh) file BEFORE calling localize.pl >>>> ? >>>> Localize.pl uses the environment variable SRC_ROOT to obtain the cws >>>> source >>>> root directory. Where this variable points to ? Is it correct? How are >>>> the >>>> file access rights for the localize.sdf files, can you write into them >>>> them? >>>> >>>> Cheers, >>>> Ivo >>>> >>>> Huda Sarfraz wrote: >>>> >>>> I followed the steps listed, and I am not getting the translation in >>>>> the >>>>> localize.sdf file. Here is what I did: >>>>> >>>>> 1. Translated the following string (in the POT files for OOH680_m12): >>>>> officecfg registry\data\org\openoffice\Office\UI\WriterCommands.xcu >>>>> 0 value >>>>> ..WriterCommands.UserInterface.Commands..uno:InsertReferenceField >>>>> Label 0 en-US Cross-reference... >>>>> 2002-02-02 >>>>> 02:02:02 >>>>> >>>>> 2. Converted the POT files to PO, and created the GSI_ur.sdf file >>>>> (using >>>>> translate-toolkit 1.1.1), and I can see the translation in the >>>>> GSI_ur.sdf >>>>> file. >>>>> >>>>> 3. Ran ./transex3/scripts/localize -m -l ur -f GSI_ur.sdf >>>>> >>>>> 4. Checked >>>>> OOH680_m12\officecfg\registry\data\org\openoffice\localize.sdf >>>>> It turns out empty, and I cannot see the string when I make the ur >>>>> build. >>>>> >>>>> I also tried running dos2unix on my GSI_ur.sdf file, but localize.sdf >>>>> still >>>>> turns out to be empty. >>>>> >>>>> Any suggestions will be appreciated, >>>>> >>>>> Thanks & Regards, >>>>> Huda >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>> 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] >>> >>> >>> >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
