A few questions about how SC will implement using PO and how translators will use this…
Pootle will use TM presumably across translated texts. Will this translation memory be publicly available as well under CC0 like the translations?
Can POT or PO files be exported for translation on local machines? If I want to do a translation that is compatible with SC segmented translations, but not using Pootle, is that possible?
If translators want to change the tags involved, such as paragraph tags and the like, how is this supported? Are the paragraphs dictated by whoever prepared the source text? Personally I like to decide exactly how the paragraphs are arranged based not on who is saying what, but according to the phase, concepts, typography, and other factors.
Currently if I want to submit a translation, I can just convert the XML to HTML, and it takes all of one minute to prepare. There are no segments to worry about, no system of references mandated by someone else, etc. It’s very flexible and compatible because HTML and plain text are basically universal.
If I already have a translation finished, though, then it seems it may require going through the entire translation, segment-by-segment, and formatting it into PO file. That is very tedious and the only purpose it serves is to be compatible with one website. If that website is your own, maybe that is worthwhile, but if it is not your website, it’s a lot of work using someone else’s arbitrary numbers and formats.
Yes. In fact there’s no difference between the two: what’s in the TM is merely the previously translated segments. Perhaps what you’re getting at is that one person’s translated segments will be available for someone else doing the translation. In this case, if I’m re-using someone else’s translated segments, that will be considered “fair use”, since I must ascertain that the translation is applicable in the new context. (Sometimes even identical strings must be translated differently). However, i think it’s appropriate that this is reflected in an attribution notice. Something like:
This translation of the Majjhima Nikaya into Klingon was made by Captain Kirk. Portions of former translations by Spock were used.
Yes, these are an open file standard, and will easily work locally on any compatible editor. I use Virtaal, by the same people who make Pootle, but there are several others. In addition, the files can be edited in a text editor. The files are readily downloadable by any editor.
The reason for making a web interface is simply that it lowers the barrier for entry, so no-one has to install anything. It also means we can hack into it our lookup tools and so on, but if you don’t want to use them, no problems. Of course given our limited resources we won’t be able to provide support for people to run stuff locally.
This is more complicated. You can’t change this stuff within the translation editor, as that is solely for translation. the best way to do this will be to download the files locally and make the changes there.
Now, when it comes to the Pali texts I will be making some changes after finishing my text, mainly to ensure more consistency and so on. Obviously it becomes complicated to run multiple variations of the Pali just for different markup (although this is again something that standoff properties would make simple). If it’s just a matter of ensuring that your translation is presented how you want it, you can make such changes to the generated HTML files in your language. As long as the ID numbers are intact, it will still match up with the Pali. However it means that if you ever want to make corrections or alterations, you can’t simply regenerate them from Pootle, you have to make all the hand changes again, too.
Indeed. It’s not meant for this, it’s meant for making translations. It is possible, as you say, to “retrofit” translations for SC, either editing the files locally or simply pasting them segment by segment into the editor, but it would be tedious work, and there’s no way of automating it. Currently we don’t have plans to do this for our old translations.
However if anyone wants to, great. Although it’s tedious, it’s certainly not unfeasible, and it would have benefits. Doing a few tens of suttas would take, I’d guess, a few hours of cut and paste.
Thanks for this. I’ve been playing around with POT and PO files, and trying out some translations of my own. So far I’ve tried Gtranslator, Poedit, Lokalize, and Virtaal.
I like the interface for Virtaal the most. Very simple and direct, and the fonts for source and target languages can be set independently. However, I’ve run into some issues with it that may be bugs (maybe…), and now the TM feature isn’t working for me at all (no new segments are added to the DB).
I switched over to Gtranslator, and that seems to work fairly well, but the interface is a bit cluttered, not as streamlined as Virtaal, and the message table fonts are kind of puny. The features all seem to work consistently with it, though, so there’s that…
There also seems to be some potential for maybe importing translated segments into my Sanzang translation tables, or converting some of those table rules into terminology usable in Virtaal and the like. The PO file format would be very easy to parse or generate.
In any case, it’s interesting to play around with. I’ve been able to get some useful results from TM, and even results that are not quite correct are often helpful in reminding me how I translated a similar segment earlier in the text.
Sounds like my experience. None of these were trivial to set up locally, and it would be unworkable to rely on them for non-geeks, and across platforms. Again, hence the web app. Which, by the way, has proved to be not at all easy to set up, but it’s working now, so we’re good. Hopefully future updates won’t break things too badly.
That would be very cool. It is precisely this kind of flexible and malleable usage that I see as one of the long-term advantages of this approach.
Exactly, it helps keep tabs on things, keep checking you former translations, see how things work out in different contexts, and so on.