Hi Emma,

У чет, 20. 11 2008. у 22:07 +0000, EmmaJane пише:
> I'm not asking for a "fix." This is a feature request or a "wishlist"
> item. I will be sad if you, Danilo, are the only developer who works
> on Launchpad Translations and you say that you will never implement
> this request.

I am not the only developer, but you might be amazed at how many things
of pretty high priority we've already got on our plate.  As I said, I am
being realistic about what we can achieve in a recent future.

I am sorry if it hurts your feelings, but that's how software
development works: there are too many excellent ideas, but you get to
implement only a small subset of them.

Would you feel better if I said: "ok, we are going to implement this in
five years time?" (maybe we are, but would you really, honestly care?).
I understand how you may be unfamiliar with bug statuses in Launchpad,
but if I wanted to say that I believe this is a silly request, I would
have marked it "Invalid", not "Won't fix".  "Won't fix" acknowledges
that this is a legitimate request, but says that this is something we
don't have time to work on.

> It doesn't seem to be in the spirit of open or more to the
> point--it doesn't seem to be in the spirit of encouraging participation
> to help distribute the work load involved in translating documents.

I offered to help set up appropriate system, and judging from your
"use-cases", I think I was correct in what you need.  You have an option
to disregard my experience (or simply not to trust me), but the choice
is yours.

> To dismiss the request because of legacy issues also makes me sad. I want
> to improve the tools. To say, "I tried once and it's too hard" does not
> seem like the right approach.

I am not sure what you are offering here, because this sounds insulting.
I think I've proven my good motives by sitting down and spending
countless hours developing a tool as a volunteer, to help other
volunteers translate documentation.

> I have identified a problem and now I
> would like to identify a solution. If there is a better place to put
> this feature request, I would like you to help me find that place so
> that we can work through the problems and find a solution!

If you want to have a discussion, launchpad-users mailing list is the
best place to have it on.  If you want to engage in a technical
discussion with Launchpad Translations developers, you can email us at
<email address hidden> as well.  Or if you've got any particular issues
you want to discuss with me (eg. get help about setting up a module for
translation using xml2po), you can find me on <email address hidden>.

> Here is the clearly defined problem that I am trying to solve: In the
> last 24 hours I have worked (as a volunteer) with two other volunteers
> who wanted to help with translations.

Thank you for sharing these two particular use cases.  I am quick to
mark a bug as "Won't fix" as soon as it's a blue-sky bug, because we get
hundreds of requests like this.  And they don't help.

> Here is a real life Problem #1 that I dealt with yesterday for nearly three hours:

And we could have instead used those 3 hours to set up a project for
translation using existing tools.

> - LP holds the "code" (DocBook XML) for the Ubuntu desktop course.
> - Volunteer downloads the files (using bzr branch) and translates them on their system using Poedit.
> - What does the volunteer do with these translated files? In their mind it is not a separate project, it is a translation of an existing project.
> - And further more the XSLT style sheets that the UDC uses are language specific. They do not work with the translation the volunteer has just spent several months (probably without backups) working on.
> - Using lp/bzr for the UDC code, there is no way to integrate a team of people --- how do you know that others are working on a translation of the project if there is no "translation" project tied to LP "code"?
> - The "code" can't be tied to translations because there is no automated way to pull in the DocBook XML files without first "branching" the content and making it into .pot files to be uploaded as a separate project. At least no way that I could find and my staging account has not been approved so I have no way of testing it.

Ok, so we are talking about a fairly technical person who:
 - can write DocBook XML
 - can create bzr branch and push it to LP
 - can prepare XSLT style sheets and use them to transform that
documentation

So, my question is why is this person unable to set up a system using
xml2po (and gnome-doc-utils)? I even offered to help with that.

If you are not familiar with how translating software using Launchpad
works, we still expect maintainers to prepare POT files and upload them
to Launchpad themselves.  They run into the same problems of how do they
do it, and Launchpad doesn't help them with that.  In my opinion, this
(automatically generating POT files for software) is a more urgent
problem than doing the same for documentation.  Why?  Simply because we
have many more non-documentation templates that need translation than
those of documentation.

And, this is also a hard problem which we are hugely behind on.  And
that's something we will do, but we won't have done in the near future
either.  And we are definitely going to work on that *before* we work on
DocBook support, especially integrated one.

Oh, and judging from the example you gave, this might also mean that you
want translation interface to be available to users with no project
attached (i.e. somebody would upload a DocBook document, and they would
be able to use Launchpad to translate it).  That's not something
Launchpad supports now (i.e. you have to set up a project, and once
something is translatable, it's translatable to all the Launchpad
languages).  This is also one of the features I'd like we implement, but
we don't have time for it, nor we need a bug about it.

> Problem #2 (dealt with this problem for about 20 minutes last night):
> - Volunteer wants to translate Ubuntu screen casts -- they log into #ubuntu-screencasts and want to work on translations TONIGHT. (Awesome!)
> - There is no "code" for a screen cast because it's a binary OGG file. Someone has to transcribe the video and then convert this into a .srt (subtitle) file. This file can now be translated.
> - But how can these transcript and translation files be stored? They do not currently fit into the "code" model of Launchpad, but they definitely fit into the concept of "translatable files."
> - The volunteer who transcribes a video is not necessarily proficient at anything other than typing what they are hearing.
> - The volunteer who translates the file is not necessarily proficient at anything other than translating what they are reading/hearing within the context of a video.
> - There is no way to facilitate the translation of these files within Launchpad Translations, and I think there should be.

One could argue about the value of keeping transcript files in a bzr
branch (it allows you to keep history and go back to something you had
changed), thus one could argue if they are "code" or not (just like
documentation).

This means that someone (Ubuntu Screencast Team?) needs to set
everything up for volunteers so it's easier for them.  I offered to help
writing a subtitle conversion tool for PO format, but that's
unacceptable to you.  Maybe it's hard to realize, but development
process is much "heavier" in Launchpad (for better or for worse), and
integration costs for such a small tool would simply be too high.

> These are common problems.

This is a very broad statement.  Let's look at it this way.  

 - People want translations for their OpenOffice Writer documents
 - People want translations for .sub subtitle files
 - People want translations for .desktop files
 - People want translations for SVG files
 - People want translations for MoinMoin wiki format
 ...

These are *all* "common problems".  Do you expect Launchpad to support
each and every one of them directly?  I say "no", especially when a
certain format could be well handled by a different tool (and converted
to PO, which we already support very well).  Eg. OpenOffice Writer
documents and SVG files are XML: why not convert them client-side with
xml2po? .desktop files are supported by intltool (and everyone is using
intltool to translate them: we've never gotten a request to support
direct .desktop file translation). SUB subtitle files should be easy to
transform to PO and back. I am not sure about MoinMoin, but I heard it
has a DocBook export.

So, if we are to support just "common" formats in Launchpad, we'd get
into a maintenance nightmare, and user support hell: we'd have to debug
all the problems users run into with their formats, and we wouldn't have
any time to actually do any development anymore (having blue-sky
discussion like this doesn't help either).

> Maybe they need to be broken into several different components. I'm not sure.

Ok, so let me put my reasoning for "Won't fix" out in the open.

 1. We are not going to get to this in the next 2 years (if you want to
discuss priorities of Launchpad Translations team, you are free to look
at our existing blueprints and stack everything against each other, and
share your thoughts and comments: we do take all of those into
consideration; I usually don't have to make this explicit, because I
trust people not to consider me a jack-ass)
 2. Do we really want to discuss something that we are not going to
implement in the next 2 years?
 3. Are we really going to forget about improving support for
documentation? No, it's not a small bug that we need to be reminded of.
 4. There are already tools that make it sufficiently easy to set up
documentation translation, yet maintainers would have to debug problems
they run into, not us for them.
 5. Blue-sky bugs which define no clear problem that one can fix tend to
be open for ages (eg. we have bug 3 and bug 7 still open), even when we
believe we've addressed most of the problems that are mentioned there.
How is it helpful to have a bug like that open?

This doesn't mean that I wouldn't like to have all the formats of this
world easily translated in Launchpad.  And DocBook ranks pretty highly
itself.  I am just saying that judging by the internal dynamics of
Launchpad Translations team, by the work involved in making such a dream
come true, and the work involved in keeping up with that dream, we are
not going to do it.  In the next few years.

> I know what the problem is, but I
> need help on the solution. I look forward to your guidance on the best
> way to solve this so that we can get even more people working on
> translating Ubuntu support material! :)

I already offered a solution: set everything up in the manner similar to
ubuntu-docs.  For translators, it would be all transparent.  For
maintainers, it would be just like for any other project maintainer in
Launchpad: a bit of manual work, but not too much.

Discussing this with Martin A. and Matthew P.T. we've agreed to open a
separate bug to direct people at using gnome-doc-utils and xml2po to set
their documentation up for translation.  That's now bug 300639.

If you decide to take my offer for help, I'd appreciate it if you use
the chance to document the entire procedure so we can put it up for
everybody else's benefit as well.

But for me, this particular bug is still a "Won't fix". So Emma, if you
still disagree, please let me know of your reasons.  Otherwise, I'll
close this bug.

Cheers,
Danilo