Excellent, this is now progress!! I have snipped the parts that are not 
a productive use of our time.

Данило Шеган wrote:
> У чет, 20. 11 2008. у 22:07 +0000, EmmaJane пише:
>> 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.

As I mentioned before, I have added documentation to the "staging" 
server to test the functionality and still have not received a response 
saying that my documents have been approved. If this is something you 
can look into, I would appreciate it.


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

Is rosetta@launchpad a discussion list? I have also emailed you directly.


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

My preference would be to keep one open and mark others as a duplicate. 
If there are so many that you have to deal with surely it would be more 
efficient to point people to where the discussion has already taken 
place than to have the discussion fresh each time? "Won't fix" is very 
different than "duplicate." Remember also that Bug #1 in Launchpad is 
about as blue-sky as it gets. ;)

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

I am the technical person, yes. The other volunteer has tried some of 
the techniques but ultimately they had no idea how they had downloaded 
the files in the first place. They followed some instructions they found 
on the internet. This does not mean they remember the instructions 
though. :)


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

As I mentioned, this volunteer is using Poedit. Probably they had made 
the conversion with xml2po. They are now stuck, however, with the files 
only on their system (as far as I know there has never been a branch 
back to the main project). Even the documentation team currently forces 
translation teams to deal with their own translated versions of the 
content for documents that are NOT part of the system documentation 
(e.g. the Wiki content). Without having a strong links it is not always 
obvious the content is even available!! That is a problem. I think it is 
a problem with the abilities of tying LP Code and LP Rosetta, but having 
not been able to test the staging environment, I cannot say for sure.


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

This is a wonderful and excellent goal!! I wish you had said this in 
your first response!


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

Where is this sort of thing documented? Do you have it as a blueprint? I 
think it saves time when you can say to people, "yes we are working on 
this, or will be working on it in the future, here is the outline of how 
it will work."


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

I don't see where I said that it was unacceptable....my response said 
that I am looking to improve the tools available in Launchpad.


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

Ideally? Yes. :) As you mention there is often a common format on the 
client side (e.g. DocBook XML). Do I expect you to implement it 
tomorrow? No. But having clearer paths within Launchpad would be a huge 
help.

> 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 am glad to know it is on the list. Again, marking this bug as a 
duplicate against these specs/blueprint/whatever format LP uses would be 
ideal!

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

Will this bug be marked a duplicate of that one?