Re: [translate-pootle] OpenOffice.org processes for Pootle

[Clytie Siddall]

Thanks for your reply, Dwayne. :)






NOT.

Then again, I just might live long enough to see it happen. ;)

On 14/08/2007, at 4:28 PM, Dwayne Bailey wrote:

Note: I have logged an issue [1] at OpenOffice.org requesting a change to XLIFF format, the professional translation standard, rich with metadata capability, extremely flexible and manipulable, and considerably superior to PO format, let along SDF which has no perceptible localization features. Naturally, this change will happen very quickly and completely invalidate our conversation here.

On Wed, 2007-08-08 at 23:29 +0930, Clytie Siddall wrote:

To: translate-pootle
Cc: Aiet Kolkhi, OpenOffice.org Pootle admin

Cc: Aijin Kim (Sun Pootle)
Cc: Pavel Janik (OpenOffice.org build/i18n/Mac guru)


Should we be Cc-ing to the l10n list at OpenOffice.org?

Cc: Mike Butler, developer of LocFactoryEditor, Mac OSX translation editor

Hi everyone :)

Now I'm back in the OpenOffice.org release maelstrom, I'd like to be
able to use Pootle more during that process. I have stayed with the
main Pootle server, to work on OpenOffice.org-specific processes.

Currently, I have to work offline during this time, as there are a
lot of quick changes required. However, I think we could manage them
via Pootle, if we had an auto-update mechanism, or a fairly straight-
forward update mechanism which the team-leader could manage.

Excellent.  I'm bringing Aijin into this conversation as she's
administering the Sun Pootle test server.

Ah, sorry, I didn't know. This is different from the OpenOffice.org Pootle server? (Oso oseyo Aijin :) )

A. UPDATING

OpenOffice.org "milestones" (more like tombstones in my sanity ;) )
are right now springing up every few days. I don't know if they are
always that frequent, but currently I have to spend quite a lot of
time just updating our translation. This means:

1. Notice that the next milestone is out.

2. Get the en-US.sdf file (original strings).

3. Convert it to a POT tree (oo2po).

4. Convert the current translation (GSI_xx.sdf) to a PO tree (oo2po).

5. Update the PO dir with the POT dir (pomigrate2).

6. Find if there are new/fuzzy strings, get the stats (pocount).

7.  Upload/publish the stats and new files for the team to access.

Just some notes.  4) Shouldn't be needed as you have the PO files that
you last translated.

4. is needed because I do global search and replaces and consistency edits in the GSI file, which is then newer than the PO files. (You try skimming through a couple of hundred PO files to check consistency in vocabulary!)

  5) Can you try pot2po, I'd like to slowly move
away from pomigrate2.  You can use pot2po within pomigrate2.

I will try that with the next update. They're coming thick and fast currently!

Ideally, the dedicated OpenOffice.org Pootle server would be synced
with the code repo, so teams could enable auto-update to the latest

milestone, with an archived directory of the previous version as backup.

I'm wondering if this should just happen automatically?

That's why I said "auto-update". But we might find some teams prefer to do this manually. The backup should help. One backup could be kept locally, with an option for further backups on nominated external storage if backups become a resource issue.

That would take care of the whole process, because the translation
would stay current on the Pootle server, Pootle makes the files and
stats available, and we can download whatever we need.

Can we do that? At least, can we do it with the OpenOffice.org Pootle
server, Aiet? If not, what help do you need to make this happen?

B. SUBMISSION

Once the translation is ready to submit, there are three different
steps:

1. Convert the PO dir. to SDF format (po2oo).

2. Upload the translation to a public address.

3. Submit an issue to the OpenOffice.org issue tracker, submitting a
translation and including the link to its public location.

I think it would be a huge help if we could do these three steps via
Pootle. Step 3 would only need to be done once per release, but steps
1 and 2 could be repeated whenever we update our translation, as they
makes an updated file available, for example, for Pavel Janik's
OpenOffice.org builds, which are regularly released. This would make
it much easier to integrate fixes.

because it was a resource hog in Pootle.  But we can use command line
tools to do the same on the server, since it has the raw PO files.

The server should then be able to serve those files.  Pavel will now

to look at this now.

We have the ability to build SDF as needed. Its disabled at the moment also have a dedicated build server for stable versions so it makes sense

Great. I have copied this email to him as well.

The translation files could be hosted on the OpenOffice.org Pootle
server, or each team could set an upload address on Pootle. So we
need these features:

(a) convert to SDF

(b) upload

(c) submit issue

(a) and (b) could be buttons on the admin interface, while (c) could
be a form, with an optional template, possibly even a link to the

OpenOffice.org Issue Tracker, with some of the fields already filled in.

Unless you want to ensure that only when the admin authorises do we
output an SDF.  Otherwise we'll be outputting on a nightly basis.

A) we can automate. B) I don't think is needed, it should be part of A.

Fine. That's actually better.

It's an advantage for resource-poor language-teams, too, that they don't have to make manual uploads. If you have a slow or unreliable connection, or small upload/download limit, it's difficult to make regular uploads. (I ran into my download limit this month, just with the OpenOffice.org builds I had to download. >140 MB each. :( ) And one of my priorities, and also a priority at Wordforge, is to support resource-poor language teams. :)

C) We can solve by have a bugzilla template link that reports your file.

Excellent! :D

C. GLOBAL CHANGES

The main advantage I've found in working with the SDF file (a
remarkably ugly and inflexible format) is that it unifies the tree of
PO files, thus making it easy to find-and-replace globally, and to go
through the file, comparing vocabulary and syntax.

How could we do this via Pootle?

Now we have a global Find, could we also have a global Replace? And
possibly a more complex Find feature, which would display all results
on one page (or more if necessary), as editable strings, to make it
easier to compare translations?

sure how easy it would be to tool.  I'm always worried about find and
replace as it needs you to check that the context is good for the
replace.

We probably need to talk more about this to see exactly how it should
work ideally.

Phew that is a big change :) The single page would be a nice idea, not

OK.











That would be really useful, and save a lot of translator time. :D

I think the onus for correct use of find and replace must be on the translator/admin concerned. You can't think for them. You could include a brief warning, I suppose. ("Make sure brain is engaged before using finger on button." ;) ) In any case, the only way we're going to get contextually-accurate translations for OpenOffice.org is by using a real translation format which stores contextual information (and supply that information!). We can do that with PO (msgctxt), but converting to SDF always dumps ALL our metadata: dates, translator names, plurals information, bug contacts, revisions etc. See my XLIFF issue. :( Once we have contextual information stored with strings, the one-page Find results will show the contextual background of each string. So you will know, before hitting Replace All, what the effect will be. Even better, have a checkbox next to each string returned by Find, plus a Select All and Deselect All button. That way, the user can decide which strings will be affected when s/he hits the Replace button.

D. CONCLUSION

Although my examples are specific to OpenOffice.org, I think similar
features would be of use to other projects.

Now, if we could only get OpenOffice.org to use XLIFF...

I'm going to submit an rather large and determined issue about the
state of OpenOffice.org translation strings, so a request to change

to XLIFF might as well be part of that. I might even live to see it. ;)

us and allow us to prove the Pootle side of the XLIFF chain.  With the
changes that the Pootling team are looking at it would mean that XLIFF

oo2xliff exists, you can actually try it now. The pot2po equivalent is
missing at the moment, but we can solve that if you are committed to
testing.

This raises a good point. I saw your emails on the OOo dev list. What I would like to propose is that a team viet? does translation in XLIFF. We need some active use to tease out the problems in Pootle using XLIFF. Would you be prepared to take that pain? It would be really helpful for becomes a format more useful then PO. And really there is no reason tho translate OOo in PO. We simply did it to make it easier then XLIFF. But

I'm certainly willing to contribute the extra time and effort.

Where do we start? :)


http://groups-beta.google.com/group/vi-VN

[1] http://www.openoffice.org/issues/show_bug.cgi?id=80789

[2] http://www.triplespin.com/en/products/locfactoryeditor.html

YES. Absolutely. My offline editor (LocFactoryEditor [2]) uses XLIFF as its base format. I would be very happy to translate OpenOffice.org in XLIFF format, both on Pootle and offline. I know Mike Butler (LFE dev) will be interested in the process, as well. (I've talked to him before about integrating with Pootle.) from Clytie (vi-VN, Vietnamese free-software translation team / nhóm Việt hóa phần mềm tự do)

PGP.sig
Description: This is a digitally signed message part

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Translate-pootle mailing list
Translate-pootle@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/translate-pootle