Hi guys, My name is Yaron and I haven't contributed to his magnificent tool in very long years.
I went through the documentation and saw that we're in 2016 and the translators still need to download the files and translate them manually.
I want to suggest an open source translation hosting and application called WebLate by Michal Cihar (The creator of Wammu/Gammu for those who remember).
This system is tightly integrated with the VCS, and the most important part: it supports Bazaar.
This is the web address: http://www.weblate.org
Michal is very kind and I really like working with WebLate.
I can do all the coordination needed and we don't need to use it exclusively so it won't interfere with the current method.
Thank you all, Yaron Shahrabani
<DevOps - Hebrew translator>
On Sat, Oct 29, 2016 at 1:56 PM, Yaron Shahrabani wrote:
I went through the documentation and saw that we're in 2016 and the translators still need to download the files and translate them manually.
They are also expected to test their respective translations and evaluate the changes live.
Alex
On Sat, Oct 29, 2016 at 4:07 PM, Alexandre Prokoudine < alexandre.prokoudine@...5...> wrote:
On Sat, Oct 29, 2016 at 1:56 PM, Yaron Shahrabani wrote:
I went through the documentation and saw that we're in 2016 and the translators still need to download the files and translate them manually.
They are also expected to test their respective translations and evaluate the changes live.
Alex
Hey Alex, I'm sorry but I failed to understand your point.
Are you against this change?
BTW, one of the features I'm trying to promote in WebLate is "celebrity strings", meaning that the users will be able to upload pictures of the UI and mark the location of the string helping other translators with the process, this feature has been moved to the next version on each and every new roadmap so far but we all hope it'll happen someday ( https://github.com/nijel/weblate/issues/250).
Kind regards,
Yaron Shahrabani
<DevOps - Hebrew translator>
On Sat, Oct 29, 2016 at 10:59 PM, Yaron Shahrabani wrote:
Are you against this change?
Pretty much yes.
BTW, one of the features I'm trying to promote in WebLate is "celebrity strings", meaning that the users will be able to upload pictures of the UI and mark the location of the string helping other translators with the process, this feature has been moved to the next version on each and every new roadmap so far but we all hope it'll happen someday (https://github.com/nijel/weblate/issues/250).
All that instead of actually using the software?
Alex
On Sat, Oct 29, 2016 at 11:14 PM, Alexandre Prokoudine < alexandre.prokoudine@...5...> wrote:
Are you against this change?
Pretty much yes.
So let's get things straight, you prefer new translators downloading Bzr client, downloading the po file, downloading and install a translation software, merge the pot file with the new changes
(not necessarily) and then work on the changes and then provide a Bazaar patch instead of logging in to a web interface and start translating? What else do you expect from the translators? to be austronauts?
I think it's time consuming and irrelevant, translator should be focused on translating.
BTW, one of the features I'm trying to promote in WebLate is "celebrity strings", meaning that the users will be able to upload pictures of the
UI
and mark the location of the string helping other translators with the process, this feature has been moved to the next version on each and
every
new roadmap so far but we all hope it'll happen someday (https://github.com/nijel/weblate/issues/250).
All that instead of actually using the software?
And what if I don't have my computer with my development tools on it and I want to see how it looks? What if I'm using a tablet and I can't install it on my device?
I can see the romantic part of the current method but if we want to get new translators on board and get more translators involved we should lower the entry point and make translations more accessible, just like I did with VLC few years ago, not only they were sending the translations over their mailing list (some of the translators still do) the mailing list had a very low threshold for file volume causing some of the transmissions to fail, very inconvenient.
I'm pro testing the translation but not at every cost, WebLate is an open source project and provides free hosting for open source projects, it's not like using Transifex, Crowdin, etc., it's a completely different method and a very convenient one with builtin glossary and comments that allows the translators to share questions about context and way of understanding a string.
If free hosting doesn't work for you there's also an installation and a docker container so you can host it yourself wherever you like, again - all open source.
What are you against exactly?
Kind regards, Yaron Shahrabani
<DevOps - Hebrew translator>
On Sat, Oct 29, 2016 at 11:53 PM, Yaron Shahrabani wrote:
What else do you expect from the translators? to be austronauts?
I expect them to be sensible, responsible human beings.
See https://musescore.org/administer-guidelines/translation-instructions for an example of how both translating online and testing the results easily could be implemented.
What are you against exactly?
Unprofessional approach to translation.
Alex
Hi,
Le 29/10/2016 à 22:53, Yaron Shahrabani a écrit :
So let's get things straight, you prefer new translators downloading Bzr client, downloading the po file, downloading and install a translation software, merge the pot file with the new changes (not necessarily) and then work on the changes and then provide a Bazaar patch instead of logging in to a web interface and start translating? What else do you expect from the translators? to be austronauts?
Our translation process is described here: http://wiki.inkscape.org/wiki/index.php/Translation_information It doesn’t require using the VCS: you can download the file and send it to us (we prefer Launchpad bug reports).
There’s also a plan of moving from Launchpad/Bazaar to a Git front-end. Should be realized in the coming year.
Nonetheless I don’t agree with Alex; I’d support any work for trying to make our translation process funnier and more accessible, even if I don’t have any idea if it will really provide better results. Let’s try!
If we use this platform then we could have a place to put screenshots of new strings for example. It’s currently hard to find where the strings are placed in the program… We could create the screenshots ourselves and that would be an opportunity to communicate among translators, as currently we don’t do it much because everybody has its own task.
Moreover I’m noticing that we don’t provide any explanation for testing the translation (weird). I’m not sure many people here are actually testing the translation with the program. Well, I did, because I made many fixes to the previous translations and was eager to see my words. But sometimes we just want the work to be quickly finished… It’s later, once we’re using the new release, that we notice the wrong texts and correct them. Quality comes with time anyway. (I’m going to write how to test your PO file — :P.)
So I’m favorable to this opening; might give motivation to the team and attract new contributors.
Do you have opinions out there, @jazzynico, @Maren or any kind translators? -- Sylvain
It's django-based - would it work as an app in the existing django website? (we'd need to keep an eye on server resources atm, though).
For website translations alone, I don't think it has a lot of advantages, we do the most important part of the translations in the cms, and I don't think that will change any time soon.
Anyway, some background info:
Martin had previously worked on a rosetta implementation for the website, but it has never been put to use, because the scope was bigger, and intended to include the website cms texts, which couldn't be done easily. It allowed to download po files, and maybe even mo files for testing.
Something like this - having it as an integral part of the website - was one of Martin's long-term goals (don't know how he thinks about it currently), to increase user-involvement.
Could be nice. I agree with Alex that quality is important. I think it could be improved by having teams where people know each other (which the website already supports) and can communicate.
As an example, I've been enjoying working together with Eduard on the German program translations (he setup a github repo for this). I think it also had a positive impact on the quality, because we reviewed each other's work and had a place to discuss the tricky things.
Regards, Maren
Am 30.10.2016 um 00:51 schrieb Sylvain Chiron:
Hi,
Le 29/10/2016 à 22:53, Yaron Shahrabani a écrit :
So let's get things straight, you prefer new translators downloading Bzr client, downloading the po file, downloading and install a translation software, merge the pot file with the new changes (not necessarily) and then work on the changes and then provide a Bazaar patch instead of logging in to a web interface and start translating? What else do you expect from the translators? to be austronauts?
Our translation process is described here: http://wiki.inkscape.org/wiki/index.php/Translation_information It doesn’t require using the VCS: you can download the file and send it to us (we prefer Launchpad bug reports).
There’s also a plan of moving from Launchpad/Bazaar to a Git front-end. Should be realized in the coming year.
Nonetheless I don’t agree with Alex; I’d support any work for trying to make our translation process funnier and more accessible, even if I don’t have any idea if it will really provide better results. Let’s try!
If we use this platform then we could have a place to put screenshots of new strings for example. It’s currently hard to find where the strings are placed in the program… We could create the screenshots ourselves and that would be an opportunity to communicate among translators, as currently we don’t do it much because everybody has its own task.
Moreover I’m noticing that we don’t provide any explanation for testing the translation (weird). I’m not sure many people here are actually testing the translation with the program. Well, I did, because I made many fixes to the previous translations and was eager to see my words. But sometimes we just want the work to be quickly finished… It’s later, once we’re using the new release, that we notice the wrong texts and correct them. Quality comes with time anyway. (I’m going to write how to test your PO file — :P.)
So I’m favorable to this opening; might give motivation to the team and attract new contributors.
Do you have opinions out there, @jazzynico, @Maren or any kind translators?
Sylvain
The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik _______________________________________________ Inkscape-translator mailing list Inkscape-translator@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-translator
Yaron Shahrabani
<DevOps - Hebrew translator>
On Sun, Oct 30, 2016 at 1:18 AM, Maren Hachmann <maren@...325...> wrote:
It's django-based - would it work as an app in the existing django website? (we'd need to keep an eye on server resources atm, though).
For website translations alone, I don't think it has a lot of advantages, we do the most important part of the translations in the cms, and I don't think that will change any time soon.
Anyway, some background info:
Martin had previously worked on a rosetta implementation for the website, but it has never been put to use, because the scope was bigger, and intended to include the website cms texts, which couldn't be done easily. It allowed to download po files, and maybe even mo files for testing.
Mozilla have a relatively new method called L20n (http://www.L20n.org) that is more suitable to website translation than gettext, also has a better individual string refrence allowing pluralizing and genderizing a single string in a different manner than all the other strings on the website. This will require separating the website translation from the other parts but it gives better agility.
Something like this - having it as an integral part of the website - was one of Martin's long-term goals (don't know how he thinks about it currently), to increase user-involvement.
Could be nice. I agree with Alex that quality is important. I think it could be improved by having teams where people know each other (which the website already supports) and can communicate.
It doesn't affect quality, professional translators all over the world are using certain tools for translation, meaning that they get the strings from the client and then they open it in a dedicated translation tool and then hand it over to the customer (which is pretty similar to what's being done right now), what I'm suggesting is to cut the middle man and give the translator a web access to what they are already doing but with less logistics.
As an example, I've been enjoying working together with Eduard on the German program translations (he setup a github repo for this). I think it also had a positive impact on the quality, because we reviewed each other's work and had a place to discuss the tricky things.
Great to hear, can I add the Hebrew translation there and connect Transifex to it?
Regards, Maren
Am 30.10.2016 um 00:51 schrieb Sylvain Chiron:
Hi,
Le 29/10/2016 à 22:53, Yaron Shahrabani a écrit :
So let's get things straight, you prefer new translators downloading Bzr client, downloading the po file, downloading and install a translation software, merge the pot file with the new changes (not necessarily) and then work on the changes and then provide a Bazaar patch instead of logging in to a web interface and start
translating?
What else do you expect from the translators? to be austronauts?
Our translation process is described here: http://wiki.inkscape.org/wiki/index.php/Translation_information It doesn’t require using the VCS: you can download the file and send it to us (we prefer Launchpad bug reports).
Not a process I would expect a professional translator to go through.
There’s also a plan of moving from Launchpad/Bazaar to a Git front-end. Should be realized in the coming year.
It supports both, so even if the transition will take very long we can still use this tool.
Nonetheless I don’t agree with Alex; I’d support any work for trying to make our translation process funnier and more accessible, even if I don’t have any idea if it will really provide better results. Let’s try!
I can show you the participation statistics to VLC, there is much less clutter and the team doesn't have to deal with merges and conflicts all day long, they just give the translators the option to work independantly and without their intervention.
If we use this platform then we could have a place to put screenshots of new strings for example. It’s currently hard to find where the strings are placed in the program… We could create the screenshots ourselves and that would be an opportunity to communicate among translators, as currently we don’t do it much because everybody has its own task.
Hold your horses :) not yet, but Michal is willing to consider it for a bounty, we can seek for external funding and have this feature pretty soon if needed.
Moreover I’m noticing that we don’t provide any explanation for testing the translation (weird). I’m not sure many people here are actually testing the translation with the program. Well, I did, because I made many fixes to the previous translations and was eager to see my words. But sometimes we just want the work to be quickly finished… It’s later, once we’re using the new release, that we notice the wrong texts and correct them. Quality comes with time anyway. (I’m going to write how to test your PO file — :P.)
I'm not an expert but I once discussed such feature with Mozilla and I see they implemented it in a way. The feature is taking pictures of the application as a part of the unit testing, this way all the dialogs are documented and the translators can see theeir work without compiling the different types of Mozilla applications (Including Android, iOS, Firefox OS, etc.), currently the coverage is pretty good for several applications but doesn't cover all of it.
So I’m favorable to this opening; might give motivation to the team and attract new contributors.
It shouldn't affect the current ones either, contributors can choose between the old and the new method as long as they're working closely with Bazaar comitting all the changes and updating constantly and resolving the conflicts beforehand.
Do you have opinions out there, @jazzynico, @Maren or any kind
translators?
-- Sylvain
The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik _______________________________________________ Inkscape-translator mailing list Inkscape-translator@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-translator
The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik _______________________________________________ Inkscape-translator mailing list Inkscape-translator@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-translator
Am 30.10.2016 um 05:40 schrieb Yaron Shahrabani:
It's django-based - would it work as an app in the existing django website? (we'd need to keep an eye on server resources atm, though).
- Do you happen to know if the django-based translation software weblate would integrate with other django systems?
Mozilla have a relatively new method called L20n (http://www.L20n.org) that is more suitable to website translation than gettext, also has a better individual string refrence allowing pluralizing and genderizing a single string in a different manner than all the other strings on the website. This will require separating the website translation from the other parts but it gives better agility.
- We are using django-cms. Will it integrate with that?
Something like this - having it as an integral part of the website - was one of Martin's long-term goals (don't know how he thinks about it currently), to increase user-involvement. Could be nice. I agree with Alex that quality is important. I think it could be improved by having teams where people know each other (which the website already supports) and can communicate.It doesn't affect quality, professional translators all over the world are using certain tools for translation, meaning that they get the strings from the client and then they open it in a dedicated translation tool and then hand it over to the customer (which is pretty similar to what's being done right now), what I'm suggesting is to cut the middle man and give the translator a web access to what they are already doing but with less logistics.
- I think we are talking past one another. I wasn't saying that the quality would be impacted negatively by adding a different tool to our belt, I was saying that it could help to build teams if we use the website for this, and that I believe that having teams can help improve quality.
As an example, I've been enjoying working together with Eduard on the German program translations (he setup a github repo for this). I think it also had a positive impact on the quality, because we reviewed each other's work and had a place to discuss the tricky things.Great to hear, can I add the Hebrew translation there and connect Transifex to it?
- I think you would have to ask Eduard about this. Currently, we only have the German files included, and use the option to comment on the commits for discussions (partially in German), so it's mostly a convenient place to coordinate our translation efforts.
Maren
On Sun, Oct 30, 2016 at 11:26 PM, Maren Hachmann <maren@...325...> wrote:
Am 30.10.2016 um 05:40 schrieb Yaron Shahrabani:
It's django-based - would it work as an app in the existing django website? (we'd need to keep an eye on server resources atm, though).
- Do you happen to know if the django-based translation software weblate
would integrate with other django systems?
I've added Michal in the first mail I sent in this thread, maybe he can assist if needed. In terms of API there's a very good support so whether it's django or python or whatever.
The other option is I didn't understand your question.
Mozilla have a relatively new method called L20n (http://www.L20n.org) that is more suitable to website translation than gettext, also has a better individual string refrence allowing pluralizing and genderizing a single string in a different manner than all the other strings on the website. This will require separating the website translation from the other parts but it gives better agility.
- We are using django-cms. Will it integrate with that?
There's a POC I ran into so I guess it does: https://github.com/stasm/django-l20n
I can ask for more assistance from Mozilla directly if needed.
Something like this - having it as an integral part of the website -was
one of Martin's long-term goals (don't know how he thinks about it currently), to increase user-involvement. Could be nice. I agree with Alex that quality is important. I thinkit
could be improved by having teams where people know each other (which the website already supports) and can communicate.It doesn't affect quality, professional translators all over the world are using certain tools for translation, meaning that they get the strings from the client and then they open it in a dedicated translation tool and then hand it over to the customer (which is pretty similar to what's being done right now), what I'm suggesting is to cut the middle man and give the translator a web access to what they are already doing but with less logistics.
- I think we are talking past one another. I wasn't saying that the
quality would be impacted negatively by adding a different tool to our belt, I was saying that it could help to build teams if we use the website for this, and that I believe that having teams can help improve quality.
Especially if there's no problem that these tools will co exist or managed in a completely different repository.
As an example, I've been enjoying working together with Eduard on the German program translations (he setup a github repo for this). Ithink
it also had a positive impact on the quality, because we reviewedeach
other's work and had a place to discuss the tricky things.Great to hear, can I add the Hebrew translation there and connect Transifex to it?
- I think you would have to ask Eduard about this. Currently, we only
have the German files included, and use the option to comment on the commits for discussions (partially in German), so it's mostly a convenient place to coordinate our translation efforts.
I did these kind of things myself several times, now I'm trying to get Kore's team attention, doesn't work so well as the past times :)
Maren
2016-10-31 11:48 GMT+01:00 Yaron Shahrabani <sh.yaron@...5...>:
On Sun, Oct 30, 2016 at 11:26 PM, Maren Hachmann <maren@...325...> wrote:
Am 30.10.2016 um 05:40 schrieb Yaron Shahrabani:
It's django-based - would it work as an app in the existing django website? (we'd need to keep an eye on server resources atm, though).
- Do you happen to know if the django-based translation software weblate
would integrate with other django systems?
I've added Michal in the first mail I sent in this thread, maybe he can assist if needed. In terms of API there's a very good support so whether it's django or python or whatever.
The other option is I didn't understand your question.
Mozilla have a relatively new method called L20n (http://www.L20n.org) that is more suitable to website translation than gettext, also has a better individual string refrence allowing pluralizing and genderizing a single string in a different manner than all the other strings on the website. This will require separating the website translation from the other parts but it gives better agility.
- We are using django-cms. Will it integrate with that?
There's a POC I ran into so I guess it does: https://github.com/stasm/django-l20n
I can ask for more assistance from Mozilla directly if needed.
Hi, there is quite a bit of time since my latest translation for Inkscape but I am still subscribed and just spotted this chat.
I am curious about why nobody raised Pootle as another choice, given that it is being used for translating plenty of free software and it is adding Mozilla's L20n support.
Bye
Something like this - having it as an integral part of the website -was one of Martin's long-term goals (don't know how he thinks about it currently), to increase user-involvement.
Could be nice. I agree with Alex that quality is important. I thinkit could be improved by having teams where people know each other (which the website already supports) and can communicate.
It doesn't affect quality, professional translators all over the world are using certain tools for translation, meaning that they get the strings from the client and then they open it in a dedicated translation tool and then hand it over to the customer (which is pretty similar to what's being done right now), what I'm suggesting is to cut the middle man and give the translator a web access to what they are already doing but with less logistics.
- I think we are talking past one another. I wasn't saying that the
quality would be impacted negatively by adding a different tool to our belt, I was saying that it could help to build teams if we use the website for this, and that I believe that having teams can help improve quality.
Especially if there's no problem that these tools will co exist or managed in a completely different repository.
As an example, I've been enjoying working together with Eduard onthe German program translations (he setup a github repo for this). I think it also had a positive impact on the quality, because we reviewed each other's work and had a place to discuss the tricky things.
Great to hear, can I add the Hebrew translation there and connect Transifex to it?
- I think you would have to ask Eduard about this. Currently, we only
have the German files included, and use the option to comment on the commits for discussions (partially in German), so it's mostly a convenient place to coordinate our translation efforts.
I did these kind of things myself several times, now I'm trying to get Kore's team attention, doesn't work so well as the past times :)
Maren
The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik _______________________________________________ Inkscape-translator mailing list Inkscape-translator@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-translator
Pootle is a wonderful option, I'm suggesting WebLate due to the tight vcs integration and screenshot support which is very important when dealing with a graphics application.
On Nov 7, 2016 21:48, "Leandro Regueiro" <leandro.regueiro@...5...> wrote:
2016-10-31 11:48 GMT+01:00 Yaron Shahrabani <sh.yaron@...5...>:
On Sun, Oct 30, 2016 at 11:26 PM, Maren Hachmann <
maren@...325...>
wrote:
Am 30.10.2016 um 05:40 schrieb Yaron Shahrabani:
It's django-based - would it work as an app in the existing django website? (we'd need to keep an eye on server resources atm,though).
- Do you happen to know if the django-based translation software weblate
would integrate with other django systems?
I've added Michal in the first mail I sent in this thread, maybe he can assist if needed. In terms of API there's a very good support so whether it's django or
python
or whatever.
The other option is I didn't understand your question.
Mozilla have a relatively new method called L20n (http://www.L20n.org
)
that is more suitable to website translation than gettext, also has a better individual string refrence allowing pluralizing and
genderizing a
single string in a different manner than all the other strings on the website. This will require separating the website translation from the other parts but it gives better agility.
- We are using django-cms. Will it integrate with that?
There's a POC I ran into so I guess it does: https://github.com/stasm/django-l20n
I can ask for more assistance from Mozilla directly if needed.
Hi, there is quite a bit of time since my latest translation for Inkscape but I am still subscribed and just spotted this chat.
I am curious about why nobody raised Pootle as another choice, given that it is being used for translating plenty of free software and it is adding Mozilla's L20n support.
Bye
Something like this - having it as an integral part of thewebsite -
was one of Martin's long-term goals (don't know how he thinks about it currently), to increase user-involvement.
Could be nice. I agree with Alex that quality is important. Ithink
it could be improved by having teams where people know each other (which the website already supports) and can communicate.
It doesn't affect quality, professional translators all over the world are using certain tools for translation, meaning that they get the strings from the client and then they open it in a dedicated
translation
tool and then hand it over to the customer (which is pretty similar to what's being done right now), what I'm suggesting is to cut the middle man and give the translator a web access to what they are already
doing
but with less logistics.
- I think we are talking past one another. I wasn't saying that the
quality would be impacted negatively by adding a different tool to our belt, I was saying that it could help to build teams if we use the website for this, and that I believe that having teams can help improve quality.
Especially if there's no problem that these tools will co exist or
managed
in a completely different repository.
As an example, I've been enjoying working together with Eduard onthe German program translations (he setup a github repo for this). I think it also had a positive impact on the quality, because we reviewed each other's work and had a place to discuss the tricky things.
Great to hear, can I add the Hebrew translation there and connect Transifex to it?
- I think you would have to ask Eduard about this. Currently, we only
have the German files included, and use the option to comment on the commits for discussions (partially in German), so it's mostly a convenient place to coordinate our translation efforts.
I did these kind of things myself several times, now I'm trying to get Kore's team attention, doesn't work so well as the past times :)
Maren
The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik _______________________________________________ Inkscape-translator mailing list Inkscape-translator@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-translator
participants (5)
-
Alexandre Prokoudine -
Leandro Regueiro -
Maren Hachmann -
Sylvain Chiron -
Yaron Shahrabani