On Wed, Aug 26, 2009 at 8:35 AM, Danilo Šegan<danilo@xxxxxxxxxxxxx> wrote: > Hi Alexey, > > Thanks a lot for your input. A few comments inline. > > У пон, 24. 08 2009. у 19:47 +0200, Alexey Balmashnov пише: > >> Somewhere in the thread it was pointed out, that translators do not >> wish anything. May be because for a while already work on improvement >> of translation tools and processes was sort of low priority? > > No, I believe it to be because it was from a different kind of > translator: the one working on an upstream project hosting their > translations in Launchpad. Where you are talking about translating > Ubuntu which has a whole lot more complications. ;) > > Also, there are not many translators on this list. We have recently > done a separate survey for translators (actually, David Planella has), > and we'll be using that as input as well. And I am pretty sure I've > seen some of your items there as well :) I talk not only about translating Ubuntu, but about whole experience ;) Hope that Rosetta (btw, does translator tools in Launchpad still codenamed like that?) will get improvements based on the survey. >> So, here we go, on the translations front... I would love if there >> were tools available to structure the translators work. >> >> 1. Some sort of locking strings/permissions mechanism >> >> There is no automation of the translation propagation to upstream. >> Want to cooperate with upstream? Get your hands dirty and do it by >> hand. But... There is no indication or whatsoever that strings to be >> translated are actually different from upstream, or not at all used in >> upstream. If one translates something, he has no clue whether this >> string might be already translated elsewhere/upstream, which surely >> leads to a duplication of work, difficulties in merging translations >> with or from upstream, which finally results in tensions between >> translators working on Ubuntu and upstream. One of the possibilities >> here might be in clear indication, that strings are unique to Ubuntu >> and ability to focus translation work around them, for example, via >> locking strings that for sure are coming from active upstream projects >> like GNOME. > > This is related to how Ubuntu packages provide their translations to > Launchpad. Note that this is a problem only for new English messages: > any changes in translations already show up appropriately marked. > > But all the problems you see can be avoided in a few different ways > (like, doing continuous imports of upstream translations and enabling > message sharing between upstream projects and Ubuntu should solve the > duplication of work and any difficulties in merging translations > around). Hm. Is there documentation somewhere, describing usage of Launchpad features within possible workflows? >> Another possible use of lock mechanism. >> >> It might be also employed in the translation process, when >> reviews are being performed, e.g. upon finishing translation and >> review string gets frozen without ability of most translator team >> members to change it directly, but only make suggestions. It might be >> based on translator quality/experience ranking based on voting system >> or somehow else. > > Note that this is entirely different from the above problem (the mere > fact that you call both features "locking" doesn't make it the same > thing ;), so it counts as another wish :P Argh. Sure, lets mark it 1-bis. >> 2. Categories (tags?) to structure translatable entities >> >> It is difficult to focus translators work on particular distribution >> or part of distribution. Currently, all translatable packages are in >> one huge non-categorized list. If translators team or part of the team >> wants to focus work on the particular flavor, extra >> organizational/administration is necessary. Yep, there are some highly >> weighted items on top of the list, like installers, documentation etc, >> but even this part of the list is messy. Clear categorization of the >> translatable packages/items by >> - flavor: ubuntu, kubuntu, ... >> - availability: e.g. installed by default vs additionally available >> applications in repositories + indication of applications popularity >> - activeness of upstream >> etc. May greatly improve translation process and quality of the >> distribution translation delivered to the end-user, which means better >> user experience. > > That's probably coming soon: we are going to model it after the > packagesets implementation in Launchpad/Ubuntu. Good to know. >> 3. Preview of translated documentation >> >> Translation process for documentation based on Rosetta >> does not take into account, that translations normally should be >> reviewed as a whole. When a number of people are translating >> particular document paragraph by paragraph, you may see this directly >> in final translated document, when you read it as a whole. Number of >> issues here. Once one is busy with chunk by chunk translation, the >> style considerations for a totality of your work are the last ones you >> think of. An even if one wants to check and proof-read final version >> of document, he/she should dig into so many technical things (bzr, >> xml, xsl, figures etc) to get the overall view on the translated >> document with a hand-driven process like: download document from >> Rosetta - generate xml/html representation of the document - read. >> Further on, upon proof-reading, all changes should be made directly in >> the Rosetta with repetition of the download, merge, generate >> proof-reading cycle. > > Yeah, this would be great: native support for XML documentation in > Launchpad. The problem might be a plethora of different documentation > formats around, but supporting one or two well should be good enough for > start. It would be very handy to have possibility of round-trip translation/review process within Launchpad. >> NN. Small bonus... [Colored] Diff-s. >> >> Suggestions and variants of translation are nice, but they >> pretty much loose their value, when someone can not recognize in a >> blink of an eye the difference between translation variants. Area of >> improvement. > > Yeah, that'd be nice, but that would be your fifth wish ;) Yep. You got me. Let me re-summarize my wishes then (damn, I have to sacrifice something). In order of importance for me... I. 1-bis. Refined access control. 3. II. 2. Structure for possible translatable items/packages. III. 3. Round-trip documentation translation. I.+II. Would be very nice to have. Since it would help very much in organizational aspects related to translators teams. III. Would help to improve quality of documentation. Thanks for comments. Cheers, Alexey Balmashnov.
This is the launchpad-users mailing list archive — see also the general help for Launchpad.net mailing lists.
(Formatted by MHonArc.)