[l10n-dev] Updated Languages list

2007-07-06 Thread Charles-H. Schulz
Hi,

since I don't have the commit rights on the L10N project, I've filed the
issue #79332 where you will find the updated languages table. Feel free
to update it and my apologies if you find mistakes in it.

Best,
Charles.

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



[l10n-dev] Translating .sdf files directly with OmegaT

2007-07-06 Thread Jean-Christophe Helary
The reason why I tried to do that is because using the .po created  
with oo2po along with the TMX created with po2tmx does not work well.  
The po2tmx removes data from escape sequences and that means more  
things to type in the OmegaT edit window.


So, the idea was to consider the .sdf file as a pseudo HTML file to  
benefit from a few automatic goodies offered by OmegaT:
1) tag reduction (so that one needs to type less when tags are  
inline) and
2) tag protection (for block tags like the ahelp.../ahelp when  
they open and close the segment)


if the TMX could be hacked to show formatting tags similar to the  
modified source file it would become trivial to edit the tags and  
reflect the new contents found in source.


Problem is, an .sdf file is not a HTML file: there is plenty of meta  
information and a lot of escaped ,  and others.
Also, a .sdf file seems to be constituted of 2 lines blocks: the  
source line and the target line.


The first problem will be solved later, now, to extract the  
translatable contents we need to change the 2 lines blocks into one  
line blocks with source and target data next to each other.


This is does using a regexp like (those are not exact, I do them from  
memory plus they may change depending on the editor you chose):


search for:
^(.*)(en-US)(.*)\r^(.*)(fr)(.*)
replace with:
\1\2\3\t\4\5\6

Now that your .sdf is linearized, change its name to .csv and open  
it in OpenOffice by using tab as field separator and nothing as  
text delimiter.


The tabs in the original .sdf create a number of columns from where  
you just need to copy the column with the en-US translatable contents.


Paste that into a text file that you'll name to .html

Now, we need to convert this to pseudo HTML. The idea being that  
OmegaT will smoothly handle all the ahelp etc tags that will be  
found there.


First of all, we need to understand that not all the  are tag  
beginning characters, a number of them are simply inferior  
characters. So we grab those first:


search for:
([^\])
replace with:
\1lt;

 are less of a problem but let's do them anyway:

search for:
([^\])
replace with:
\1gt;

Now we can safely assume that all the remaining  or  are  
escaped with \ and to correct that (so that the non escaped tags  
can be recognized in OmegaT) do:


search for:
\\
replace with:


search for:
\\
replace with:


Last but not least, to ensure that OmegaT will consider each line as  
being a segment we need to add the paragraph mark to each line  
beginning:


search for:
^
replace with:
p

Save, the file should be ready to be processed.



Now, we need to get matches from the TMX files that either we have  
created (oo2po - po2tmx) or that Rafaella  all have provided us with.


Problem is that the TMX files reflect the contents of the .sdf that  
we have just modified.


In the TMX, we are likely to find an ahelp tag written as \ahelp  
something\ which will not be helpful since in OmegaT the ahelp tag  
will be displayed as a0 and thus will not match the \ahelp  
something\ string.


So, we need to hack the file so that it looks close enough to what  
the source expects...


In the TMX we want to reduce _all_ the escaped tags to a short  
expression that looks like a for a tag starting with a.


So we would do something like (here again, not 100% exact regexp).

search for:
\\(.)[^]*
replace with:
lt;\1gt;

same for tail tags:
\\/(.)[^]*
replace with:
lt;/\1gt;

If I remember well everything I did in the last few days that is  
about it. Save the TMX, put it in /tm/, load the project and  
translate...


You can also put the Sun glossaries in /glossary/ after a little bit  
of formatting. But that too is trivial.



When translation is done, it is important to verify the tags (Tool -  
Valitate tags) click on each segment where the tags don't with source  
and correct the target.


Then Project - Create translated files

Get the translated .html file from /target/

And now we need to back process the whole thing to revert it to its  
original .sdf form.


1) remove all the p at the beginning of the lines
2) replace all the  with \, all the  with \, all the lt; with   
and the gt; with 



This should be enough. Now copy the whole file and paste it in the  
target contents part of the still opened .csv file.


The .csv file now contains the source part and the target part next  
to each other.


Let's save this (be careful: tab as field separator and nothing  
as text delimiter).


Open the result in the text editor.

The pattern we need to find to revert the 1 line blocks to 2 line  
blocks is something like:


(something)(followed by lots of en-US stuff)a tab(the same something) 
(followed by lots of translated stuff)


^([^\t])(.*)\t\1(.*)$
and we need to replace it with:
\1\2\r\1\4

Make sure there are no mistakes (if there are any they are likely to  
appear right in the first lines).


Now you should have your 2 lines block.

Rename the file to .sdf and here you are.



This 

Re: [l10n-dev] Error with PO files form Pootle

2007-07-06 Thread Alessandro Cattelan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

F Wolff ha scritto:
 Op Woensdag 04-07-2007 om 13:12 uur [tijdzone +0200], schreef Alessandro
 Cattelan:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 F Wolff ha scritto:
 Op Woensdag 04-07-2007 om 11:52 uur [tijdzone +0200], schreef Alessandro
 Cattelan:

 ...

 I translated a couple of files offline using OmegaT, writing only the
 text in the msgstr field as in example 2 above. When I upload that file
 to Pootle, the server does not consider the strings with that sort of
 inline comment translated so I have to go through the translation again
 with Pootle. Am I doing something wrong?

 I must say that I don't like translating with Pootle - it's a nice tool
 to manage the translation workflow but it's not as good when it comes to
 translating. What I'm doing is translate and review the files offline
 (with OmegaT or with a text editor) and then upload them to Pootle. I'd
 like to know whether there is a way to automatically mark as translated
 and reviewed strings edited offline.


 Ale.

 I just want to make sure I understand well what you are describing.

 Were the relevant messages already translated, or did you newly
 translate these messages? If a message is already translated and a file
 with translations is uploaded, changes to already translated messages
 are accepted as suggestions that have to be reviewed. Is this what you
 are referring to?

 Not exactly. Let's say that the file I had to translate had 100 strings.
 80 were already translated. 10 contained the inline comments of my
 previous message and the remaining 10 strings were just plain text, with
 no tags and no comments (something like msgid Open).

 I translated the whole file offline and then uploaded it to Pootle using
 the overwrite option. Before I started translating it, Pootle reported
 that the file had 20 strings to be translated. After uploading it,
 Pootle reported that I still had to translate 10 strings.

 I used the Quick Translate command from Pootle to see which strings
 were to be translated and it came out that they were the ones with the
 inline comments, such as:

 #:masterpassworddlg.src#DLG_UUI_MASTERPASSWORD.FT_MASTERPASSWORD.fixedtext.text
 msgid 
 _:
 masterpassworddlg.src#DLG_UUI_MASTERPASSWORD.FT_MASTERPASSWORD.fixedtext.
 text\n
 Master password
 msgstr Password principale

 
 Can you provide the URL to the file, please? I'll try to have a look at
 it.


Sorry, we (the Italian L10N team) were trying to finish off the
translation on Pootle and I forgot to send you the URL. We'll be working
on Pootle again in the next few weeks - I'll let you know if we have any
problem.

Ale.


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGjq0Rdpk3ZlYYJ+gRAp0xAKC2L7nxvzzPlm19HXJyFnwYYBopnwCfflSY
zxAk9TxdOvI0a7HMf2ejiHs=
=zUG9
-END PGP SIGNATURE-

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