Hi, as the release date for 0.48 is nearing, I am once again trying to find the most appropriate way to translate the Release Notes from the Wiki. Translating Wiki texts is always a hassle because there are no CAT (computer aided translation) tools that support the format (OmegaT does something with MediaWiki format, but I haven't been able to try it out !!). As I was researching a solution to this problem I found the TranslateWiki project (http://translatewiki.net/). They provide a translation platform for wikis of open source projects. The main advantage of it is that translations become _reusable_. Instead of translating the same texts over and over again from one release to another and having to check every sentence word by word for changes, we will be able to reuse previous translations and the differences will be highlighted.
I'd like to hear your thoughts on whether it would be useful for us to use their platform.
Some links: Requirements for new projects: http://translatewiki.net/wiki/Translating:New_project Projects already using translatewiki.net: http://translatewiki.net/wiki/Project_list
Cheers, -- Lucas Vieites
Hello Lucas,
I personally prefer .po files because I'm most efficient with them as opposed to different web interfaces like Launchpad, Pootle, Translatewiki etc. But I understand other, especially novice translators might be more comfortable with those. I have no problem with adopting and supporting a website as an alternative translation platform but I expect the good old way to remain available.
I've been using Translatewiki to translate MediaWiki for a few years now and I've seen its development. Are there any specific question you would like to ask?
Regards, ~~helix84
Hi, just to clarify my position: I don't pretend to substitute the currently used gettext .po files that are used for the GUI, but only the Wiki pages (also, I agree with your comment about Launchpad, etc.). I strongly believe in "using the right tool for the task". In the same way that I don't agree with the decision that was taken to convert the tutorials to .po files for translation, and then converting them back again to svg format, I would not find it "logical" to convert the wiki texts to .po and then back again. I think that that would be a waste of effort if there already is an easier way to automate the task.
I don't have any experience using translatewiki (yet), so I don't know if it really would be an easier way to keep inkscape's wiki translations up to date. Could you shed some light here?
Cheers,
2010/8/19 helix84 <helix84@...150...>
Hello Lucas,
I personally prefer .po files because I'm most efficient with them as opposed to different web interfaces like Launchpad, Pootle, Translatewiki etc. But I understand other, especially novice translators might be more comfortable with those. I have no problem with adopting and supporting a website as an alternative translation platform but I expect the good old way to remain available.
I've been using Translatewiki to translate MediaWiki for a few years now and I've seen its development. Are there any specific question you would like to ask?
Regards, ~~helix84
--- Оригінальне повідомлення --- Від кого: "Lucas Vieites" <lucas@...162...> Кому: "Inkscape translators" inkscape-translator@lists.sourceforge.net Дата: 19 серпня, 12:13:12 Тема: Re: [Inkscape-translator] Wiki page translation
Hi, just to clarify my position: I don't pretend to substitute the currently used gettext .po files that are used for the GUI, but only the Wiki pages (also, I agree with your comment about Launchpad, etc.). I strongly believe in "using the right tool for the task". In the same way that I don't agree with the decision that was taken to convert the tutorials to .po files for translation, and then converting them back again to svg format, I would not find it "logical" to convert the wiki texts to .po and then back again. I think that that would be a waste of effort if there already is an easier way to automate the task.
Hi!
In fact Translatewiki can export and import data in PO format.
I don't have any experience using translatewiki (yet), so I don't know if it really would be an easier way to keep inkscape's wiki translations up to date. Could you shed some light here?
I have some experience on KDE UserBase ( http://userbase.kde.org/ ). Translation can be merged with the current page manually or by the bot.
Yuri
Cheers,
2010/8/19 helix84 <helix84@...150...>
Hello Lucas,
I personally prefer .po files because I'm most efficient with them as opposed to different web interfaces like Launchpad, Pootle, Translatewiki etc. But I understand other, especially novice translators might be more comfortable with those. I have no problem with adopting and supporting a website as an alternative translation platform but I expect the good old way to remain available.
I've been using Translatewiki to translate MediaWiki for a few years now and I've seen its development. Are there any specific question you would like to ask?
Regards, ~~helix84
This SF.net email is sponsored by
Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev
On Thu, Aug 19, 2010 at 11:13, Lucas Vieites <lucas@...162...> wrote:
just to clarify my position: I don't pretend to substitute the currently used gettext .po files that are used for the GUI, but only the Wiki pages
If I understand it correctly, you don't want to translate Inkscape GUI using Translatewiki, you want to translate Inkscape website wiki pages using Translatewiki. I don't think that's reasonable - Translate wiki is string-based, not page-based, so it will not make this job easier. I originally understood you want to enable current .po files to be translated via Translatewiki (as Yuri said, they do .po import/export), that would be reasonable.
In the same way that I don't agree with the decision that was taken to convert the tutorials to .po files for translation, and then converting them back again to svg format, I would not find it "logical" to convert the wiki texts to .po and then back again. I think that that would be a waste of effort if there already is an easier way to automate the task.
Here I don't agree with you - the task is automated. And import/export of translations to some web translation platform would also be automated, .po files wouldn't disappear, only translators would not work with them directly.
I don't have any experience using translatewiki (yet), so I don't know if it really would be an easier way to keep inkscape's wiki translations up to date. Could you shed some light here?
I think this is highly subjective - which one each translator prefers. Recently there was such transition going on in LXDE and they were deciding between Transifex and Pootle (Translatewiki was probably also mentioned) and every translator had his say in that. You can look it up in the archives.
But like I said, this is not for wiki pages.
Regards, ~~helix84
Hi,
2010/8/19 helix84 <helix84@...150...>
On Thu, Aug 19, 2010 at 11:13, Lucas Vieites <lucas@...162...> wrote:
just to clarify my position: I don't pretend to substitute the
currently
used gettext .po files that are used for the GUI, but only the Wiki pages
If I understand it correctly, you don't want to translate Inkscape GUI using Translatewiki, you want to translate Inkscape website wiki pages using Translatewiki. I don't think that's reasonable - Translate wiki is string-based, not page-based, so it will not make this job easier. I originally understood you want to enable current .po files to be translated via Translatewiki (as Yuri said, they do .po import/export), that would be reasonable.
I that case you are right, this tool does not fit my/our needs for documentation translation.
In the same way that I don't agree with the decision that was taken to convert the tutorials to .po files
for
translation, and then converting them back again to svg format, I would
not
find it "logical" to convert the wiki texts to .po and then back again. I think that that would be a waste of effort if there already is an easier
way
to automate the task.
Here I don't agree with you - the task is automated. And import/export of translations to some web translation platform would also be automated, .po files wouldn't disappear, only translators would not work with them directly.
I understand your point of view, but still, I would like to have an easy way to translate wiki pages without having to check for changes manually. Any ideas?
I don't have any experience using translatewiki (yet), so I don't know
if
it really would be an easier way to keep inkscape's wiki translations up
to
date. Could you shed some light here?
I think this is highly subjective - which one each translator prefers. Recently there was such transition going on in LXDE and they were deciding between Transifex and Pootle (Translatewiki was probably also mentioned) and every translator had his say in that. You can look it up in the archives.
But like I said, this is not for wiki pages.
Regards, ~~helix84
Cheers, -- Lucas Vieites http://www.codexion.com
On Fri, Aug 20, 2010 at 09:30, Lucas Vieites <lucas@...162...> wrote:
I understand your point of view, but still, I would like to have an easy way to translate wiki pages without having to check for changes manually. Any ideas?
1) I translated a lot of wiki page (not for Inkscape, though) 2) I used the diff on the original page to locate changes. This worked for me. 3) I can't think of any significat improvement.
One thing that could be automated is to provide a link on translated pages to a diff of the original page from date the translated page was modified to today (because that's what you're doing manually most of the time).
I may suggest this at Translatewiki. But I don't think it will go to the mainline MediaWiki tree and we use MediaWiki at Inkscape. But still we can use it if the changes won't be extensive. The prerequisite would be to have a standard on flagging translated and original pages which we currently don't. My suggestion would be different namespaces (de:Hauptseite) or subpages (Main Page/de). This is a good idea anyway.
Regards, ~~helix84
participants (3)
-
helix84 -
Lucas Vieites -
Yuri Chornoivan