ubuntu-manual team mailing list archive
Mailing list archive
Re: Not happy at all
On Wed, Dec 22, 2010 at 6:26 PM, Kevin Godby <godbyk@xxxxxxxxx> wrote:
> Hello, Hannie.
> On Wed, Dec 22, 2010 at 9:44 AM, lafeber-dumoleyn2
> <lafeber-dumoleyn2@xxxxxxxxx> wrote:
>> If authors who write new versions only add new strings, and do not add minor
>> changes to strings that already exist, our problem is solved. LP will
>> transfer all the old strings and their translations, as long as they have
>> not changed. There is no problem with new strings, as I mentioned before.
>> As for Lucid-e2, I have no intention of reviewing it in LP as long as this
>> problem occurs. But it is a pity for all those people who have spent time
>> and effort on translating strings that had already been translated and will
>> not be reviewed.
>> I hope that the Natty version will be based on Lucid-e1 plus ONLY NEW
>> LP is not to blame in this. It is quite logical that they only transfer
>> translations of identical strings.
> The Maverick edition is based on Lucid-e2, and Natty will likely be
> based on Maverick. We continue to edit from the most recent version.
> A number of the Lucid-e2 strings changed because I moved the margin
> notes around. I actually moved them in Lucid-e1, but it was done just
> prior to publishing and after the writing freeze. I didn't push those
> changes to Launchpad because it would've caused the same problems
> you're seeing now.
> As far as I recall, there at no substantial changes between Lucid-e1
> and Lucid-e2 -- just fixing some typos, grammatical errors, and
> formatting issues.
> We can't simply add new text and leave the existing text as is or we
> wouldn't have the opportunity to fix these bugs.
> Ideally, our translation system would handle these fuzzy matches by
> highlighting the differences between the two strings so that the
> translator can easily determine whether the new string warrants a new
> translation. It'd be nice if the system could also manage continuous
> updates. So instead of waiting for a writing freeze and having an
> entire book dumped in your lap, you could start translating
> immediately. Anything that had been previously translated would stay
> in the system and not be lost when the original strings are updated.
> Any altered strings would be show to the translator (as mentioned
> earlier) for review.
> Currently, our translation software works at the paragraph level.
> That is, each string is a full paragraph. The benefit of this (aside
> from it being easier for the LaTeX-to-pot-file converter) is that it
> allows the translators to rearrange sentences within the paragraph or
> rewrite the entire paragraph as they see fit. This means that the
> translated edition will sound more natural and flow better. The
> downside is that if anything in that paragraph changes, Launchpad
> tosses out the original translation and you have to start over again.
> We've tossed around the idea of ditching Launchpad and creating our
> own translation system, but I haven't had time to research the issue
> or think about it much yet. We'd need to sit down with translators,
> editors, and developers to establish what our needs are and what a
> translation system is actually capable of doing. If you have any
> suggestions or ideas with regard to this sort of thing (or would like
> to kick off a discussion about it), I'd love to hear them!
> Mailing list: https://launchpad.net/~ubuntu-manual
> Post to : ubuntu-manual@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-manual
> More help : https://help.launchpad.net/ListHelp
My opinion on what we need technically:
Fuzzy matching and a word-wise po-file diffing utility.
The only way to do this without doing lots of development first, I
think, is to use off-line tools. This also means that it'll be more
difficult to contribute than if we were using Launchpad. However it
would be straightforward for people with some technical experience.
The tricky issue is that while Launchpad would be suited for
first-time translations, it's not possible to set up things so that
people will work on one sensible version in LP and no other versions.
I don't think the paragraphs should be split into more strings. The
benefit of being able to split/merge sentences is probably important
for some languages, and at least beneficial for almost all languages.
In free-flowing text it is also very difficult for the translator to
guess what is being referred to by words like "this" or "that", since
that probably depends on the contents of the last sentence. Then you
would need to look at the full text to translate it at all, and you
might as well open the tex file and just rewrite that in a new
language. Which is also a possibility of course.