В Втр, 26/09/2006 в 09:20 +0200, Roman Joost пишет: > Hi Nickolay and others, > > sorry for replying so late, but I haven't had time to reply earlier. > > Let me first say, that this discussion comes always up if new > contributors joining us. We should put some of the conclusions up on our > wiki, so we don't have to argue about some points again and again. > Although it might be sometimes good to get new ideas. Anyways ... > I completely agree with that point. Every change breaks something and introduces new bugs, migration process is very important thing and it should be documented. I'll create wiki page about po vs docbook soon with the results of our discussion here. > Let me please first reply to the disadvantages: > > On Fri, Sep 22, 2006 at 03:35:36PM +0400, Nickolay V. Shmyrev wrote: > > Disadvantages > > > > 1. Translator that use po files will have to precisely follow English > > content. Note, that it still will be possible to write additional > > translated content directly in source files, so I think it's a minor > > problem. > And IMHO this is our problem: we don't have a finished English > manual yet. If we want to use PO files, we need a reference to make a > translation for. DocBook provides the basis of not creating just a plain > translation of a reference manual written in a specific language. It > provides the (IMHO the advantage) possibilities to write your "own" > translated manual. Of course the structure is and should be the same, so > is the content. But if you describe e.g. the quickmask in a single > sentence or in a big article is up to you. > Well, I agree completely. But one of the reasons we don't have complete English content is that we are working on different contents actually as you pointed above. It gives you freedom to ignore English completely and many of us use this freedom leaving English content unfinished. If translator should follow the English content, he will try to improve it as well. But it's just a thought :) > So we have currently: > -> more flexibility > -> no reference language to create a translation for > > > 2. Development will require additional tools - python and libxml2- > > python. I think it's a minor requirement. > Yep - think so as well. > > > [...] 3. > > > > 4. No way to translate images right now from po, translation should > > go directly to the content. We'll solve this technical problem later. > Excuse my ignorance, but thats always how people come up with new ideas. > I love to have new ideas and how we can improve the way we're writing > content for the manual. But new technologies come also with a lot of > disadvantages. > Let me explain the situation with images since Sally is also interested. xml2po has nice support for translation of images - it stores the hash of the image in po file in the following way: #. When image changes, this message will be marked fuzzy or untranslated for you. #. It doesn't matter what you translate it to: it's not used at all. #: C/evince.xml:146(None) msgid "@@image: 'figures/evince_start_window.png'; md5=7f4da5e33bcac35738a268d93d497d47" msgstr "@@image: 'figures/evince_start_window.png'; md5=7f4da5e33bcac35738a268d93d497d47" So if original image will change, translator will be aware of it. It also allows transparent switching to untranslated image when translated one is not present. But the way it is working is a bit incompatible with our current way. More precisely, it relays on the following directory structure C/figures/image1.png ru/figures/image1.png You see that lang should be in the beginning of the path. Currently we have a bit different layout: menus/figures/image1.png menus/figures/ru/image1.png so we can't translate images, but I think I'll patch xml2po soon so it will use our layout. > To make it short: I think we just don't gain any benefit of changing to > po. We will run in other problems equivalent to what we now have. > > > Advantages: > > > > 1. We'll lower translation contribution barrier. Translation process > > will be faster since translators won't care about docbook and will > > just use existing tools. > > > > 2. We'll track changes simpler and keep translated content up-to-date. > > > > 3. Translators won't affect each other and content writers and will > > work with their own files. > Yep - everything a *pro* of course. > > > > > Proposal > > > > I propose to apply the attached files. Basically, it modifies profiling > > the following way. If po file for language does not exist, it works > > as before. If file exists, it profiles for both $lang and en, replaces > > en with translations according to po files, and then strips untranslated > > en content. It works nicely, so I propose just to commit it and > > encourage new translators to work with po instead while keeping the > > existing content in place. For example, we can start to translate menus > > part into Russian with po files. > Did I understand that correctly that we can have the advantages of both > worlds? (Sorry haven't looked at your patch, but it'll probably cost me > another day to reply to your mail then which I don't want.) > Yes, please look on it, really it tries to merge both world instead of replacing one with another. Thus we will be able to use as previous content and previous way of translation and we will be able to use a new way. And I completely agree that we should identify the problems first and try to solve them, not just do a migration because somebody did it. > Greetings, > _______________________________________________ > Gimp-docs mailing list > Gimp-docs@xxxxxxxxxxxxxxxxxxxxxx > https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-docs
Attachment:
signature.asc
Description: =?koi8-r?Q?=FC=D4=C1?= =?koi8-r?Q?_=DE=C1=D3=D4=D8?= =?koi8-r?Q?_=D3=CF=CF=C2=DD=C5=CE=C9=D1?= =?koi8-r?Q?_=D0=CF=C4=D0=C9=D3=C1=CE=C1?= =?koi8-r?Q?_=C3=C9=C6=D2=CF=D7=CF=CA?= =?koi8-r?Q?_=D0=CF=C4=D0=C9=D3=D8=C0?=
_______________________________________________ Gimp-docs mailing list Gimp-docs@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-docs
