Hi,

I followed the same steps again, and now it is working and I can see the
translation! I haven't figured out what I was doing wrong though. I was
following the same steps each time. However, this time I used "build"
instead of "dmake", but I don't think that this should make a difference.

Thank you for your help and suggestions :) I will now try to incorporate all
our translations,

Regards,
Huda

On Thu, May 22, 2008 at 3:57 PM, Huda Sarfraz <[EMAIL PROTECTED]>
wrote:

> 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]
>>
>>
>

Reply via email to