From sylvestre.ledru at scilab.org Wed May 4 11:25:33 2011 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Wed, 04 May 2011 11:25:33 +0200 Subject: [Scilab-loc] Settings for the scilab localization in LaunchPad Translations In-Reply-To: References: Message-ID: <1304501133.1263.124.camel@korcula.inria.fr> Hello Kenneth, Le mercredi 27 avril 2011 ? 18:14 +0200, Kenneth Nielsen a ?crit : > Hallo [...] > So in short my suggestion is to assign the translation of Scilab to > the ~launchpad-translators group and ask your existing translators to > join the respective language teams within that group. OK. Thanks for the suggestions. I just changed to Restricted + "Translation group" to "Launchpad Translators". > When it comes to deciding between "Structured" and "Restricted" then > it is really a matter of where you priority lie between quantity and > quality when it comes to how many languages you cover. The difference > concerns the languages for which there is no person or team assigned > within the group. With "Structured" permissions the translations for > that language will then be open to everyone, with "Restricted" > permissions it is closed to all. I would suggest making it > "Restricted" since that ensures maximum quality. At first, we were more interested in the quantity but for now, we have plenty of translations and I believe you are right, it is time to switch it to Restricted. Do you think I should contact the launchpad translators group or they will be informed ? Sylvestre From sylvestre.ledru at scilab.org Wed May 4 11:33:32 2011 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Wed, 04 May 2011 11:33:32 +0200 Subject: [Scilab-loc] Settings for the scilab localization in LaunchPad Translations In-Reply-To: References: Message-ID: <1304501612.1263.127.camel@korcula.inria.fr> I am copying and pasting the email of Yuri which has been stuck in the moderation queue (and which I just saw) Kenneth, what is your opinion on this ? I am not familiar enough with launchpad/translation to judge here... Hi, ???????? Wed, 27 Apr 2011 19:15:03 +0300, Kenneth Nielsen [via Scilab / Xcos - Mailing Lists Archives] <[hidden email]>: > So in short my suggestion is to assign the translation of Scilab to > the ~launchpad-translators group and ask your existing translators to > join the respective language teams within that group. Please do not do this. Some of ~launchpad-translators groups are dead and cannot be reached (at least Ukrainian one). It will be very hard for me to maintain the translation if you do so. There is no reason to restrict open project translation by just Ubuntu users or Ubuntu teams. I have no reasonable proof that the quality of these group translations (at least in case of Ukrainian and Russian) are in any kind better than the quality of open translations. Just my 5 cents. Best regards, Yuri Le mercredi 27 avril 2011 ? 18:14 +0200, Kenneth Nielsen a ?crit : > Hallo > > I am interested in starting to translate Scilab into Danish and I had > a look at the project in Launchpad and I noticed a few things I think > might be set up better. I hope you will consider these humble > suggestions. > > I Launchpad there are four settings for translation permissions, > "Open", "Structured", "Restricted" and "Closed". For Scilab it is set > to "Structured", which means that if there is a team or person > assigned to a language within the group that is assigned to the entire > translation*, the only that team or group can make contributions and > if there isn't assigned a team of person to a language within that > group, then it is open to everyone. The thing is, that there is no > group assigned to the translation, which means that the defacto > results is that it is open, which I am guessing wasn't the purpose > since you set it to "Structured". If you value quality in the > translation, then it should indeed be set to "Structured" or > "Restricted" and assign the translation to a group. You could off > course form a Scilab specific group on launchpad and assign the > translation to that group, but there is actually already one set up > for exactly this purpose, the ~launchpad-translators group. This group > has the purpose of translation all the independent projects on > Launchpad and therefore already has language teams with active > translators set up. > > So in short my suggestion is to assign the translation of Scilab to > the ~launchpad-translators group and ask your existing translators to > join the respective language teams within that group. > > When it comes to deciding between "Structured" and "Restricted" then > it is really a matter of where you priority lie between quantity and > quality when it comes to how many languages you cover. The difference > concerns the languages for which there is no person or team assigned > within the group. With "Structured" permissions the translations for > that language will then be open to everyone, with "Restricted" > permissions it is closed to all. I would suggest making it > "Restricted" since that ensures maximum quality. > > Regards Kenneth Nielsen > > * Launchpad makes the distinction between translation groups and > teams. Groups are assigned to the task of localizing into all > languages and consist of teams that localize into a single language ;) From k.nielsen81 at gmail.com Thu May 5 11:58:53 2011 From: k.nielsen81 at gmail.com (Kenneth Nielsen) Date: Thu, 5 May 2011 11:58:53 +0200 Subject: [Scilab-loc] Settings for the scilab localization in LaunchPad Translations In-Reply-To: <1304501133.1263.124.camel@korcula.inria.fr> References: <1304501133.1263.124.camel@korcula.inria.fr> Message-ID: Hallo 2011/5/4 Sylvestre Ledru : > Hello Kenneth, > > Le mercredi 27 avril 2011 ? 18:14 +0200, Kenneth Nielsen a ?crit : >> Hallo > [...] > >> So in short my suggestion is to assign the translation of Scilab to >> the ~launchpad-translators group and ask your existing translators to >> join the respective language teams within that group. > OK. Thanks for the suggestions. I just changed to Restricted + > "Translation group" to "Launchpad Translators". Great >> When it comes to deciding between "Structured" and "Restricted" then >> it is really a matter of where you priority lie between quantity and >> quality when it comes to how many languages you cover. The difference >> concerns the languages for which there is no person or team assigned >> within the group. With "Structured" permissions the translations for >> that language will then be open to everyone, with "Restricted" >> permissions it is closed to all. I would suggest making it >> "Restricted" since that ensures maximum quality. > At first, we were more interested in the quantity but for now, we have plenty of translations > and I believe you are right, it is time to switch it to Restricted. > > Do you think I should contact the launchpad translators group or they > will be informed ? I asked David Planella (who knows such thing) and his answer was that it is probably a good idea. It will also give you an opportunity to advertise a little for your project to get even more translators on board. Regards Kenneth From k.nielsen81 at gmail.com Thu May 5 13:09:20 2011 From: k.nielsen81 at gmail.com (Kenneth Nielsen) Date: Thu, 5 May 2011 13:09:20 +0200 Subject: [Scilab-loc] Settings for the scilab localization in LaunchPad Translations In-Reply-To: <1304501612.1263.127.camel@korcula.inria.fr> References: <1304501612.1263.127.camel@korcula.inria.fr> Message-ID: Hallo Sylvester 2011/5/4 Sylvestre Ledru : > I am copying and pasting the email of Yuri which has been stuck in the > moderation queue (and which I just saw) > > Kenneth, what is your opinion on this ? > I am not familiar enough with launchpad/translation to judge here... Yes I'll try an answer. > Hi, > > ???????? Wed, 27 Apr 2011 19:15:03 +0300, Kenneth Nielsen [via > Scilab / > Xcos - Mailing Lists Archives] > <[hidden email]>: > >> So in short my suggestion is to assign the translation of Scilab to >> the ~launchpad-translators group and ask your existing translators to >> join the respective language teams within that group. > > Please do not do this. Some of ~launchpad-translators groups are dead > and > cannot be reached (at least Ukrainian one). It will be very hard for me > to > maintain the translation if you do so. It is true that it can happen that a Lauchpad translators team run out of steam and become inactive. However, the appropriate way to solve that then is to try and take over the team and revive it (which Yuri actually is doing now). Please consider this: The launchpad translators group is meant to be a gathering project for all the independent projects in Launchpad, so if language team cannot be maintained there, then it is unlikely that it can around just at single project. So if you want to assign a group to your translation to provide them with the opportunity to make translations of higher quality, then surely this group is the best bet. > There is no reason to restrict open project translation by just > Ubuntu > users or Ubuntu teams. I have no reasonable proof that the quality of > these group translations (at least in case of Ukrainian and Russian) > are > in any kind better than the quality of open translations. Well first off, there a few things that need to be cleared up. The Launchpad translators group has nothing to do with Ubuntu nor is it specific to Ubuntu users. Launchpad is a generic code hosting site with support for translation, specification and bug tracking and answers. Ubuntu is just one of the projects being hosted on this site, even though it certainly is the biggest. That is also the reason why it has its own translators-group with its own translation teams, which has nothing to do with launchpad-translators. Just to re-iterate, lauchpad-translators is created for all the "little" independent projects in LP and being a member of that group only requires that you have a LP-account, NOT that you are a Ubunt user. As for quality. You are correct that restricting translations to a group like launchpad translators, does not _guarantee_ that the translations will become of high quality, but it does give the teams, that are willing to make an effort to produce the high quality translations, the tools (and control) to make that possible, tools that don't have if the translations is open. Regards Kenneth > > Just my 5 cents. > > Best regards, > Yuri > > Le mercredi 27 avril 2011 ? 18:14 +0200, Kenneth Nielsen a ?crit : >> Hallo >> >> I am interested in starting to translate Scilab into Danish and I had >> a look at the project in Launchpad and I noticed a few things I think >> might be set up better. I hope you will consider these humble >> suggestions. >> >> I Launchpad there are four settings for translation permissions, >> "Open", "Structured", "Restricted" and "Closed". For Scilab it is set >> to "Structured", which means that if there is a team or person >> assigned to a language within the group that is assigned to the entire >> translation*, the only that team or group can make contributions and >> if there isn't assigned a team of person to a language within that >> group, then it is open to everyone. The thing is, that there is no >> group assigned to the translation, which means that the defacto >> results is that it is open, which I am guessing wasn't the purpose >> since you set it to "Structured". If you value quality in the >> translation, then it should indeed be set to "Structured" or >> "Restricted" and assign the translation to a group. You could off >> course form a Scilab specific group on launchpad and assign the >> translation to that group, but there is actually already one set up >> for exactly this purpose, the ~launchpad-translators group. This group >> has the purpose of translation all the independent projects on >> Launchpad and therefore already has language teams with active >> translators set up. >> >> So in short my suggestion is to assign the translation of Scilab to >> the ~launchpad-translators group and ask your existing translators to >> join the respective language teams within that group. >> >> When it comes to deciding between "Structured" and "Restricted" then >> it is really a matter of where you priority lie between quantity and >> quality when it comes to how many languages you cover. The difference >> concerns the languages for which there is no person or team assigned >> within the group. With "Structured" permissions the translations for >> that language will then be open to everyone, with "Restricted" >> permissions it is closed to all. I would suggest making it >> "Restricted" since that ensures maximum quality. >> >> Regards Kenneth Nielsen >> >> * Launchpad makes the distinction between translation groups and >> teams. Groups are assigned to the task of localizing into all >> languages and consist of teams that localize into a single language ;) > > > From yurchor at ukr.net Thu May 5 17:06:44 2011 From: yurchor at ukr.net (Yuri Chornoivan) Date: Thu, 5 May 2011 08:06:44 -0700 (PDT) Subject: Settings for the scilab localization in LaunchPad Translations In-Reply-To: References: <1304501612.1263.127.camel@korcula.inria.fr> Message-ID: Hi again, ???????? Thu, 05 May 2011 14:09:33 +0300, Kenneth Nielsen [via Scilab / Xcos - Mailing Lists Archives] : > Hallo Sylvester > > 2011/5/4 Sylvestre Ledru : >> I am copying and pasting the email of Yuri which has been stuck in the >> moderation queue (and which I just saw) >> >> Kenneth, what is your opinion on this ? >> I am not familiar enough with launchpad/translation to judge here... > > Yes I'll try an answer. > >> Hi, >> >> ???????? Wed, 27 Apr 2011 19:15:03 +0300, Kenneth Nielsen [via >> Scilab / >> Xcos - Mailing Lists Archives] >> <[hidden email]>: >> >>> So in short my suggestion is to assign the translation of Scilab to >>> the ~launchpad-translators group and ask your existing translators to >>> join the respective language teams within that group. >> >> Please do not do this. Some of ~launchpad-translators groups are dead >> and >> cannot be reached (at least Ukrainian one). It will be very hard for me >> to >> maintain the translation if you do so. > > It is true that it can happen that a Lauchpad translators team run out > of steam and become inactive. However, the appropriate way to solve > that then is to try and take over the team and revive it (which Yuri > actually is doing now). That is not true. I do not want to revive the team. I just want to adapt to the new strict requirements of Scilab translation. > Please consider this: The launchpad > translators group is meant to be a gathering project for all the > independent projects in Launchpad, so if language team cannot be > maintained there, then it is unlikely that it can around just at > single project. This gathering is absolutely senseless. There is not much common things between Chromium, ADempiere ERP, and Scilab. > So if you want to assign a group to your translation > to provide them with the opportunity to make translations of higher > quality, then surely this group is the best bet. It is not true. The parent groups of these groups (Ubuntu translators) is of higher quality and quantity. >> There is no reason to restrict open project translation by just >> Ubuntu >> users or Ubuntu teams. I have no reasonable proof that the quality of >> these group translations (at least in case of Ukrainian and Russian) >> are >> in any kind better than the quality of open translations. > > Well first off, there a few things that need to be cleared up. The > Launchpad translators group has nothing to do with Ubuntu nor is it > specific to Ubuntu users. Launchpad is a generic code hosting site > with support for translation, specification and bug tracking and > answers. Ubuntu is just one of the projects being hosted on this site, > even though it certainly is the biggest. That is also the reason why > it has its own translators-group with its own translation teams, which > has nothing to do with launchpad-translators. Just to re-iterate, > lauchpad-translators is created for all the "little" independent > projects in LP and being a member of that group only requires that you > have a LP-account, NOT that you are a Ubunt user. That is not true again. Consider Danish translation team. https://launchpad.net/~lp-l10n-da/+members#active It consists almost exclusively (I am not sure about 1 member) of Ubuntu translation team members. > As for quality. You are correct that restricting translations to a > group like launchpad translators, does not _guarantee_ that the > translations will become of high quality, but it does give the teams, > that are willing to make an effort to produce the high quality > translations, the tools (and control) to make that possible, tools > that don't have if the translations is open. Let's see the stats. LP-translators is a confederation of 42 teams. These teams have to manage 276 projects. Most of the teams consist of 3-4 members (taking into account even people with zero karma). What quality control are you talking about? They cannot even review the propositions. This can be clearly seen by the mailing list: https://lists.launchpad.net/launchpad-translators/ There are no messages for months. LiVES developer asked them to give LiVES new translations: https://lists.launchpad.net/launchpad-translators/msg00136.html and... The only 100% translation was given by the guy who did not even know about LP-translators. https://translations.launchpad.net/lives/trunk/+pots/lives ------------------------------------------------------------------------------------------- Let's analyze the current state of affairs. Scilab top contributors Rui Hirokawa 1450 points - not a member of lp-translators Fido 900 points - member of lp-translators Yuri Chornoivan 707 points - not a member of lp-translators Ondrej Sta? 701 points - not a member of lp-translators Carml 700 points - member of lp-translators Well, I propose that Kenneth (1 point of Scilab karma) send a message to all the current Scilab translators with the larger Scilab karma and propose them to join lp-translators. To be serious, if you do not want to loose half (at least) of Scilab translators, please change the policy to "Structured" or "Open". LP-translators cannot give nor quantity, neither quality of translations, but the current translators can. If you are still not sure, please create "Scilab translators" and approve its members by yourself or give open permissions. Restrictions like "lp-translators" do not work. It can be easily seen on the Chromium example. These restrictions just narrow down the number of translators with no quality advantage. Best regards, Yuri -- View this message in context: http://mailinglists.scilab.org/Settings-for-the-scilab-localization-in-LaunchPad-Translations-tp2870916p2903774.html Sent from the Scilab localization - Mailing Lists Archives mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvestre.ledru at scilab.org Thu May 5 23:10:14 2011 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Thu, 05 May 2011 23:10:14 +0200 Subject: [Scilab-loc] Re: Settings for the scilab localization in LaunchPadTranslations In-Reply-To: References: <1304501612.1263.127.camel@korcula.inria.fr> Message-ID: <1304629814.13201.6.camel@losinj.inria.fr> Le jeudi 05 mai 2011 ? 08:06 -0700, Yuri Chornoivan a ?crit : > > To be serious, if you do not want to loose half (at least) of Scilab > > translators, please change the policy to "Structured" or "Open". > LP-translators cannot give nor quantity, neither quality of > translations, > but the current translators can. OK, thanks for your feedback. Until we sorted this out, I rollback to "Structured" like it use to be. Sylvestre From rodolforg at gmail.com Fri May 6 04:20:01 2011 From: rodolforg at gmail.com (Rodolfo) Date: Thu, 5 May 2011 23:20:01 -0300 Subject: [Scilab-loc] Re: Settings for the scilab localization in LaunchPadTranslations In-Reply-To: <1304629814.13201.6.camel@losinj.inria.fr> References: <1304501612.1263.127.camel@korcula.inria.fr> <1304629814.13201.6.camel@losinj.inria.fr> Message-ID: 2011/5/5 Sylvestre Ledru : > Until we sorted this out, I rollback to "Structured" like it use to be. Thank you. I know Brazilian Ubuntu/TP translation team has very bad quality work at the moment: incoherence, some bad mistranslations, mispells, hurry over quality. I've been working hard the last two years in order to control the quality and coherence here for portuguese brasilian. Att, Rodolfo From rokach at tu.kielce.pl Thu May 5 19:01:06 2011 From: rokach at tu.kielce.pl (Ihor Rokach) Date: Thu, 5 May 2011 19:01:06 +0200 Subject: [Scilab-loc] Re: Settings for the scilab localization in LaunchPad Translations In-Reply-To: References: <1304501612.1263.127.camel@korcula.inria.fr> Message-ID: Yuri, I agree with you totally. Most of the Open Source translation projects were, are and will be the one-man ones. Idea of creation of so called 'translation groups' maybe could be useful for some projects, however, is totally senseless in the Scilab case. Actually it adds nothing to the quality of translation of Scilab or even decrease it because it kills effort of causal translators which help us by correction of one or two strings only. These people need to have easy and simple access to the translation interface, otherwise they simply will not participate in the translation process. I know examples of the projects with completely restrict-less access to the translation interface which are extremely successful. See for example SMath Studio (freeware Mathcad clone) translation interface at http://smath.info/translator/ If Launchpad team do not understand this it would be better for Sylvestre to move Scilab translation to the another place. --Igor From sylvestre.ledru at scilab.org Fri May 6 09:44:18 2011 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Fri, 06 May 2011 09:44:18 +0200 Subject: Upcoming release of Scilab Message-ID: <1304667858.3302.20.camel@losinj.inria.fr> Hello, Probably next week, we are going to release Scilab 5.3.2. I will synchronize the localization today and probably next monday morning. If you want to update some localizations, it is the time ;) thanks S From k.nielsen81 at gmail.com Fri May 6 11:01:00 2011 From: k.nielsen81 at gmail.com (Kenneth Nielsen) Date: Fri, 6 May 2011 11:01:00 +0200 Subject: [Scilab-loc] Re: Settings for the scilab localization in LaunchPad Translations In-Reply-To: References: <1304501612.1263.127.camel@korcula.inria.fr> Message-ID: >>> >>>> So in short my suggestion is to assign the translation of Scilab to >>>> the ~launchpad-translators group and ask your existing translators to >>>> join the respective language teams within that group. >>> >>> Please do not do this. Some of ~launchpad-translators groups are dead >>> and >>> cannot be reached (at least Ukrainian one). It will be very hard for me >>> to >>> maintain the translation if you do so. >> >> It is true that it can happen that a Lauchpad translators team run out >> of steam and become inactive. However, the appropriate way to solve >> that then is to try and take over the team and revive it (which Yuri >> actually is doing now). > That is not true. I do not want to revive the team. I just want to adapt > to the new strict requirements of Scilab translation. I didn't say that you _wanted_ to do it or were happy with, I simply said that you were in the process of doing it. The last we spoke in IRC we discussed the possibility of you assuming leadership of the team, purely for the purpose of translating scilab through that team and the passing leadership on whenever someone showed up. And you seemed willing to do that. If I misunderstood or expressed myself imprecisely earlier I apologize. >> Please consider this: The launchpad >> translators group is meant to be a gathering project for all the >> independent projects in Launchpad, so if language team cannot be >> maintained there, then it is unlikely that it can around just at >> single project. > > This gathering is absolutely senseless. There is not much common things > between Chromium, ADempiere ERP, and Scilab. The gathering is not one of projects that have things in common, but of translators who work on small projects. This way translators can collaborate across project boundaries. So if I do this translations, then when I'm done, I will ask someone on the team to proofread it and someone who does not have anything to do with Scilab translations will, because then later I will proofread something for him. >> So if you want to assign a group to your translation >> to provide them with the opportunity to make translations of higher >> quality, then surely this group is the best bet. > > It is not true. The parent groups of these groups (Ubuntu translators) is > of higher quality and quantity. Once again. Ubuntu translators is not structurally, or with the regard to purpose, the parent group for the launchpad translators group. >>> There is no reason to restrict open project translation by just >>> Ubuntu >>> users or Ubuntu teams. I have no reasonable proof that the quality of >>> these group translations (at least in case of Ukrainian and Russian) >>> are >>> in any kind better than the quality of open translations. >> >> Well first off, there a few things that need to be cleared up. The >> Launchpad translators group has nothing to do with Ubuntu nor is it >> specific to Ubuntu users. Launchpad is a generic code hosting site >> with support for translation, specification and bug tracking and >> answers. Ubuntu is just one of the projects being hosted on this site, >> even though it certainly is the biggest. That is also the reason why >> it has its own translators-group with its own translation teams, which >> has nothing to do with launchpad-translators. Just to re-iterate, >> lauchpad-translators is created for all the "little" independent >> projects in LP and being a member of that group only requires that you >> have a LP-account, NOT that you are a Ubunt user. > That is not true again. Consider Danish translation team. > > https://launchpad.net/~lp-l10n-da/+members#active > > It consists almost exclusively (I am not sure about 1 member) of Ubuntu > translation team members. Yes there is quite a lot a overlap in personnel, which means that we just happen to have a lot a people that are interested both in the translation of Ubuntu and in the translations of small projects on Launchpad. That does not change the fact that they are two different groups with two completely different purposes. If you are interested only in translating Ubuntu, then you become a member of that group. If you are interested only translating independent projects in the Launchpad but want nothing to do with with Ubuntu because you are a Fedora user, than you only become a member of the other group. We do not require people to join both groups and that is an important point. >> As for quality. You are correct that restricting translations to a >> group like launchpad translators, does not _guarantee_ that the >> translations will become of high quality, but it does give the teams, >> that are willing to make an effort to produce the high quality >> translations, the tools (and control) to make that possible, tools >> that don't have if the translations is open. > > Let's see the stats. LP-translators is a confederation of 42 teams. These > teams have to manage 276 projects. Most of the teams consist of 3-4 > members (taking into account even people with zero karma). > > What quality control are you talking about? They cannot even review the > propositions. You need only 2 people to implement a proper proofreading workflow. As for how many projects they can cover? The groups of Danish translators that maintain the GNOME desktop translation (about 80 modules), is about a 3 people, doing so with a complete translate-proofread-correct-integrate workflow and with a few people extra we also take case of quite a few of the modules in the gnome-extras. But you are correct, teams of 3-4 people might not be able to review all of the suggestions by drive-by-translators, but in the process of proofreading and hopefully getting into some dialogue with the people that suggested the translations they might get more proofreaders and so on. In any case, when you say: "They cannot even review the propositions." then you make an assumption that I don't agree with and that is that they indeed need to get around to all the modules. I will much rather have a program be in English than poorly translated to Danish, so when we (and the other teams) have the resources to make the quality translations then we will, otherwise the remain in English and that is as it should be. > This can be clearly seen by the mailing list: > > https://lists.launchpad.net/launchpad-translators/ > > There are no messages for months. LiVES developer asked them to give LiVES > new translations: > > https://lists.launchpad.net/launchpad-translators/msg00136.html > > and... The only 100% translation was given by the guy who did not even > know about LP-translators. > > https://translations.launchpad.net/lives/trunk/+pots/lives If now one replied then it is probably because no one in interested in translating LiVES. It is a video editor, not something that Linux is known for doing well, so it can't be a surprise that it is difficult to find translators. But that does not mean that they would be better off accepting the translations of anyone that just happens to drop by, totally independent of language and grammar skills. > ------------------------------------------------------------------------------------------- > > Let's analyze the current state of affairs. > > Scilab top contributors > > Rui Hirokawa 1450 points ?- not a member of lp-translators > Fido 900 points - member of lp-translators > Yuri Chornoivan 707 points - not a member of lp-translators > Ondrej Sta? 701 points - not a member of lp-translators > Carml 700 points - member of lp-translators > > Well, I propose that Kenneth (1 point of Scilab karma) send a message to > all the current Scilab translators with the larger Scilab karma and > propose them to join lp-translators. That is what I just did and you can think about that exactly what you want I don't care much. I did that one string just to see if it was actually true that indeed anyone could write strings there directly, but you see, I wont contribute as much as a single string to any project, let alone ask my team to help proofread it, if it is not under some level of control, if I cannot be assured that our hard and thorough work cannot just be overwritten by someone that just happens to pass by. That is the way that I choose to work. If Scilab decides to do it differently, then I wont loose any sleep over that. I'll just find another project that does care about quality. There are plenty of projects that are hungry for translator contributions. > To be serious, if you do not want to loose half (at least) of Scilab > translators, please change the policy to "Structured" Structured wont make a difference in the case where launchpad-translators have inactive language teams. As I already explained, the difference between structures and restricted is what happens if there is no team for a language. > or "Open". LP-translators cannot give nor quantity, neither quality of translations, > but the current translators can. I disagree but the is off course the choice if the Scilab teamm > If you are still not sure, please create "Scilab translators" and approve > its members by yourself That is the next best solution. This will allow me the control I need in order for med to contribute. Personally it is not a solutions I like, but that is because I contribute to many projects and the bureaucracy if maintaining a group for each one of them is not something absolutely horrible. > or give open permissions. see above > Restrictions like > "lp-translators" do not work. It can be easily seen on the Chromium > example. These restrictions just narrow down the number of translators > with no quality advantage. Yes, they will narrow down the number of contributors, but as for quality I don't think you are right. I have about half a decade worth of experience with translating free software so I know the kind of and amount of errors you will find in a proofreading. But as I said earlier, assigning the translation to a group and making it restricted or structured off course does not guarantee higher quality, that depends on the members, but it does give those of us that care about quality the tools we need. Regards Kenneth From sylvestre.ledru at scilab.org Fri May 6 11:13:10 2011 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Fri, 06 May 2011 11:13:10 +0200 Subject: [Scilab-loc] Re: Settings for the scilab localization in LaunchPadTranslations In-Reply-To: References: <1304501612.1263.127.camel@korcula.inria.fr> <"BANLkTimARd_M=OX7okKpKeW yEA3FWWxQYA"@mail.gmail.com> Message-ID: <1304673190.3302.59.camel@losinj.inria.fr> Le vendredi 06 mai 2011 ? 11:01 +0200, Kenneth Nielsen a ?crit : > If Scilab decides > to do it differently, then I wont loose any sleep over that. I'll just > find another project that does care about quality. There are plenty of > projects that are hungry for translator contributions. We are interested by translator contributions... It is something I cannot myself :) I am trying to understand both points of view and to find a consensus. > > To be serious, if you do not want to loose half (at least) of Scilab > > translators, please change the policy to "Structured" > > Structured wont make a difference in the case where > launchpad-translators have inactive language teams. As I already > explained, the difference between structures and restricted is what > happens if there is no team for a language. > > > or "Open". LP-translators cannot give nor quantity, neither quality of translations, > > but the current translators can. > > I disagree but the is off course the choice if the Scilab teamm I tend to agree that people more involved in teams will produce better translations before of their involvements. However, AFAIK, launchpad restricted introduces to much "constraints" for new comers. Don't forget that most of Scilab users are not geeks but mathematicians and physicists. > > If you are still not sure, please create "Scilab translators" and approve > > its members by yourself > > That is the next best solution. This will allow me the control I need > in order for med to contribute. OK. I like this potential good solution. Any one has an objection for this solution ? Thanks From k.nielsen81 at gmail.com Fri May 6 11:15:08 2011 From: k.nielsen81 at gmail.com (Kenneth Nielsen) Date: Fri, 6 May 2011 11:15:08 +0200 Subject: [Scilab-loc] Re: Settings for the scilab localization in LaunchPad Translations In-Reply-To: References: <1304501612.1263.127.camel@korcula.inria.fr> Message-ID: 2011/5/5 Ihor Rokach : > Yuri, > > I agree with you totally. Most of the Open Source translation projects > were, are and will be the one-man ones. Joining a team in a gathering group like Launchpad translators, will (if you get the team of the ground) allow you to get help with the proofreading, turning it into an at least 2 man job. I have contributed to jmol, rednotebook, Ubuntu Pay and others in this way me translating and someone else proofreading or the other way around and it works just fine. > Idea of creation of so called > 'translation groups' ?maybe could be useful for some projects, > however, is totally senseless in the Scilab case. Actually it adds > nothing to the quality of translation of Scilab or even decrease it > because it kills effort of causal translators which help us by > correction of one or two strings only. You can't do proper QA by a casual effort. > These people need to have easy > and simple access to the translation interface, otherwise they simply > will not participate in the translation process. Making translations something that you can contribute to with this kind of hit-and-run contributions is a huge mistake. I don't know who ever came up with that idea but it is horrible. Translations, just like programming or documentations writing, requires a little more effort that that to do it right. That was the way the Launchpad started out and they have now realized that effect that has on quality and therefore now, still allow it, but recommends restrictions after the upstart phase > I know examples of the projects with completely restrict-less access > to the translation interface which are extremely successful. See for > example SMath Studio (freeware Mathcad clone) translation interface at > > http://smath.info/translator/ Success in terms of what? Quantity I'll believe, quality, not likely. > If Launchpad team do not understand this it would be better for > Sylvestre to move Scilab translation to the another place. You can run it in any way you want in Launchpad, even despite the recommendations. Regards Kenneth From k.nielsen81 at gmail.com Fri May 6 11:22:14 2011 From: k.nielsen81 at gmail.com (Kenneth Nielsen) Date: Fri, 6 May 2011 11:22:14 +0200 Subject: [Scilab-loc] Re: Settings for the scilab localization in LaunchPadTranslations In-Reply-To: References: <1304501612.1263.127.camel@korcula.inria.fr> <1304629814.13201.6.camel@losinj.inria.fr> Message-ID: 2011/5/6 Rodolfo : > 2011/5/5 Sylvestre Ledru : >> Until we sorted this out, I rollback to "Structured" like it use to be. > > Thank you. I know Brazilian Ubuntu/TP translation team has very bad > quality work at the moment: incoherence, some bad mistranslations, > mispells, hurry over quality. As I have already mentioned, changing it to structured wont make a difference in the case of inactive or "bad" teams. If a team exists for your language within the group assigned to the translation, then the translations for that language will be restricted to that team whether you use restricted or structured. It only makes it open for the languages that does not have a team within the group. > I've been working hard the last two years in order to control the > quality and coherence here for portuguese brasilian. > > Att, > Rodolfo > From k.nielsen81 at gmail.com Fri May 6 11:49:27 2011 From: k.nielsen81 at gmail.com (Kenneth Nielsen) Date: Fri, 6 May 2011 11:49:27 +0200 Subject: [Scilab-loc] Re: Settings for the scilab localization in LaunchPadTranslations In-Reply-To: <1304673190.3302.59.camel@losinj.inria.fr> References: <1304501612.1263.127.camel@korcula.inria.fr> <1304673190.3302.59.camel@losinj.inria.fr> Message-ID: 2011/5/6 Sylvestre Ledru : > Le vendredi 06 mai 2011 ? 11:01 +0200, Kenneth Nielsen a ?crit : >> If Scilab decides >> to do it differently, then I wont loose any sleep over that. I'll just >> find another project that does care about quality. There are plenty of >> projects that are hungry for translator contributions. > We are interested by translator contributions... It is something I > cannot myself :) > I am trying to understand both points of view and to find a consensus. Sure. I was just saying to underline that I am not some nut out on a crusade. It was not a threat, just a fact about how I work. I, like my team, and like many other have limited resources. I translate on a volunteer basis and I only have limited spare time. Therefore I can only contribute to a limited number projects and so I simply use these things as some of the criteria I use to select which one to contribute to. >> > To be serious, if you do not want to loose half (at least) of Scilab >> > translators, please change the policy to "Structured" >> >> Structured wont make a difference in the case where >> launchpad-translators have inactive language teams. As I already >> explained, the difference between structures and restricted is what >> happens if there is no team for a language. >> >> > or "Open". ?LP-translators cannot give nor quantity, neither quality of translations, >> > but the current translators can. >> >> I disagree but the is off course the choice if the Scilab teamm > I tend to agree that people more involved in teams will produce better translations before of their involvements. > However, AFAIK, launchpad restricted introduces to much "constraints" > for new comers. > Don't forget that most of Scilab users are not geeks but mathematicians > and physicists. Well, since there is a Danish team in launchpad translators Structures or Restricted wont make a bit of difference for me. Lets just make sure we all understand what the difference is, see some of my other mails. >> > If you are still not sure, please create "Scilab translators" and approve >> > its members by yourself >> >> That is the next best solution. This will allow me the control I need >> in order for med to contribute. > > OK. I like this potential good solution. Any one has an objection for > this solution ? Well as I wrote above, unnecessary bureaucracy is also one of the criteria that I use to select projects that I want to contribute to. But it is not as strict a requirement of mine, in those cases I determine it on a case to case basis dependent on how much I want to contribute to the given project. I e.g. participate in vlc and pidgin translations, even though they insist on using their own infrastructure which means that I get added a few more email lists to my subscriptions, which I don't really like. However, before you make such a change you should understand how it will work. The following will happen. Common for restricted and structured is that if you do assign a team or person within that group to the translations into a language, then it will be restricted to that team or person (so people casually dropping by cannot contribute). If you don't assign a person or team to the translation into a language, then the translation into that language will be open to all. If you make it a policy not assign anybody to the languages and use structured then the result is the same as open, and you might as well keep that. Regards Kenneth From yurchor at ukr.net Fri May 6 12:05:24 2011 From: yurchor at ukr.net (Yuri Chornoivan) Date: Fri, 6 May 2011 03:05:24 -0700 (PDT) Subject: Settings for the scilab localization in LaunchPadTranslations In-Reply-To: References: <1304501612.1263.127.camel@korcula.inria.fr> <1304673190.3302.59.camel@losinj.inria.fr> Message-ID: <1304676324015-2907544.post@n3.nabble.com> If the above makes Danish translation of Scilab possible, I agree with any Kenneth suggestion as long as Ukrainian one will not be touched in any kind. On the other hand, if there will be no contribution from Danish team I think the decision to choose stricter rules to be canceled as no other language team expressed the will to change the rules. -- View this message in context: http://mailinglists.scilab.org/Settings-for-the-scilab-localization-in-LaunchPad-Translations-tp2870916p2907544.html Sent from the Scilab localization - Mailing Lists Archives mailing list archive at Nabble.com. From yurchor at ukr.net Fri May 6 12:29:51 2011 From: yurchor at ukr.net (Yuri Chornoivan) Date: Fri, 6 May 2011 03:29:51 -0700 (PDT) Subject: Settings for the scilab localization in LaunchPad Translations In-Reply-To: References: <1304501612.1263.127.camel@korcula.inria.fr> Message-ID: > 2011/5/5 Ihor Rokach <[hidden email]>: > > Yuri, > > > > I agree with you totally. Most of the Open Source translation projects > > were, are and will be the one-man ones. > > Joining a team in a gathering group like Launchpad translators, will > (if you get the team of the ground) allow you to get help with the > proofreading, turning it into an at least 2 man job. I have > contributed to jmol, rednotebook, Ubuntu Pay and others in this way me > translating and someone else proofreading or the other way around and > it works just fine. I am KDE and Fedora coordinator and Opera Software official volunteer translator. For sure, I cannot understand what prevents you from doing this now. Just call your reviewers and they correct the mistakes. Do you want to ban some "bad" guys that ruined your translations? That is easy, file a question on LP. ;) > > > Idea of creation of so called > > 'translation groups' maybe could be useful for some projects, > > however, is totally senseless in the Scilab case. Actually it adds > > nothing to the quality of translation of Scilab or even decrease it > > because it kills effort of causal translators which help us by > > correction of one or two strings only. > > You can't do proper QA by a casual effort. Why? I believe that not all of us are professionals in translation. Why casual reviewer (we are all casual reviewers) cannot fix casual translator (do not tell me that you will leave forever and translate Scilab to the end of times)? > > > These people need to have easy > > and simple access to the translation interface, otherwise they simply > > will not participate in the translation process. > > Making translations something that you can contribute to with this > kind of hit-and-run contributions is a huge mistake. I don't know who > ever came up with that idea but it is horrible. Translations, just > like programming or documentations writing, requires a little more > effort that that to do it right. That was the way the Launchpad > started out and they have now realized that effect that has on quality > and therefore now, still allow it, but recommends restrictions after > the upstart phase > Well, who can judge who are right 3 Ubuntu translators or 3 KDE translators? There are no conflicts between Scilab translators. We were working together to make the translations better. But then someone find that we should not give the opportunity to the new translators and reviewers and it appears that there are groups of translators (lp-translators) that know things better but did not translate Scilab because of the wrong rules > > I know examples of the projects with completely restrict-less access > > to the translation interface which are extremely successful. See for > > example SMath Studio (freeware Mathcad clone) translation interface at > > > > http://smath.info/translator/ > > Success in terms of what? Quantity I'll believe, quality, not likely. Can you give an example of the faulty translation? > > > If Launchpad team do not understand this it would be better for > > Sylvestre to move Scilab translation to the another place. > > You can run it in any way you want in Launchpad, even despite the > recommendations. > > > Regards Kenneth > Best regards, Yuri -- View this message in context: http://mailinglists.scilab.org/Settings-for-the-scilab-localization-in-LaunchPad-Translations-tp2870916p2907597.html Sent from the Scilab localization - Mailing Lists Archives mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvestre.ledru at scilab.org Fri May 6 12:30:15 2011 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Fri, 06 May 2011 12:30:15 +0200 Subject: [Scilab-loc] Re: Settings for the scilab localization inLaunchPadTranslations In-Reply-To: References: <1304501612.1263.127.camel@korcula.inria.fr> <"B ANLkTimARd_M=OX7okKpKeWyEA3FWWxQYA"@mail.gmail.com> <1304673190.3302.59.camel@losinj.inria.fr> Message-ID: <1304677815.3302.102.camel@losinj.inria.fr> Le vendredi 06 mai 2011 ? 11:49 +0200, Kenneth Nielsen a ?crit : > 2011/5/6 Sylvestre Ledru : > > Le vendredi 06 mai 2011 ? 11:01 +0200, Kenneth Nielsen a ?crit : > >> If Scilab decides > >> to do it differently, then I wont loose any sleep over that. I'll just > >> find another project that does care about quality. There are plenty of > >> projects that are hungry for translator contributions. > > We are interested by translator contributions... It is something I > > cannot myself :) > > I am trying to understand both points of view and to find a consensus. > > Sure. I was just saying to underline that I am not some nut out on a > crusade. It was not a threat, just a fact about how I work. I, like my > team, and like many other have limited resources. I translate on a > volunteer basis and I only have limited spare time. Therefore I can > only contribute to a limited number projects and so I simply use these > things as some of the criteria I use to select which one to contribute > to. Sure! I am not arguing on it. > >> > To be serious, if you do not want to loose half (at least) of Scilab > >> > translators, please change the policy to "Structured" > >> > >> Structured wont make a difference in the case where > >> launchpad-translators have inactive language teams. As I already > >> explained, the difference between structures and restricted is what > >> happens if there is no team for a language. > >> > >> > or "Open". LP-translators cannot give nor quantity, neither quality of translations, > >> > but the current translators can. > >> > >> I disagree but the is off course the choice if the Scilab teamm > > I tend to agree that people more involved in teams will produce better translations before of their involvements. > > However, AFAIK, launchpad restricted introduces to much "constraints" > > for new comers. > > Don't forget that most of Scilab users are not geeks but mathematicians > > and physicists. > > Well, since there is a Danish team in launchpad translators Structures > or Restricted wont make a bit of difference for me. Lets just make > sure we all understand what the difference is, see some of my other > mails. OK, Danish is OK but as far as I know, some lp teams are empty. > >> > If you are still not sure, please create "Scilab translators" and approve > >> > its members by yourself > >> > >> That is the next best solution. This will allow me the control I need > >> in order for med to contribute. > > > > OK. I like this potential good solution. Any one has an objection for > > this solution ? > > Well as I wrote above, unnecessary bureaucracy is also one of the > criteria that I use to select projects that I want to contribute to. For now, it is what we have, you just need a lp account to contribute to it. > However, before you make such a change you should understand how it > will work. The following will happen. Common for restricted and > structured is that if you do assign a team or person within that group > to the translations into a language, then it will be restricted to > that team or person (so people casually dropping by cannot > contribute). If you don't assign a person or team to the translation > into a language, then the translation into that language will be open > to all. If you make it a policy not assign anybody to the languages > and use structured then the result is the same as open, and you might > as well keep that. OK, thanks for the explanations. So, a thing I could do could be to try to chat active people (or identifying them). Chat with them if they agree to join/create a team. If they are OK, let's go for it. Otherwise, I don't not assign any team and leave it like now. How does it sound ? Sylvestre From k.nielsen81 at gmail.com Fri May 6 13:30:52 2011 From: k.nielsen81 at gmail.com (Kenneth Nielsen) Date: Fri, 6 May 2011 13:30:52 +0200 Subject: [Scilab-loc] Re: Settings for the scilab localization in LaunchPadTranslations In-Reply-To: <1304676324015-2907544.post@n3.nabble.com> References: <1304501612.1263.127.camel@korcula.inria.fr> <1304673190.3302.59.camel@losinj.inria.fr> <1304676324015-2907544.post@n3.nabble.com> Message-ID: 2011/5/6 Yuri Chornoivan : > If the above makes Danish translation of Scilab possible, I agree with any > Kenneth suggestion as long as Ukrainian one will not be touched in any kind. > > On the other hand, if there will be no contribution from Danish team I think > the decision to choose stricter rules to be canceled as no other language > team expressed the will to change the rules. Don't make this change purely on my account. I cannot and will not guarantee commitment. As you have already pointed out, I'm not really a part of your community yet, so I shouldn't really have a say. It was just a suggestion, you make the decision. From k.nielsen81 at gmail.com Fri May 6 13:42:29 2011 From: k.nielsen81 at gmail.com (Kenneth Nielsen) Date: Fri, 6 May 2011 13:42:29 +0200 Subject: [Scilab-loc] Re: Settings for the scilab localization in LaunchPad Translations In-Reply-To: References: <1304501612.1263.127.camel@korcula.inria.fr> Message-ID: 2011/5/6 Yuri Chornoivan : >> 2011/5/5 Ihor Rokach <[hidden email]>: >> ?> Yuri, >> ?> >> ?> I agree with you totally. Most of the Open Source translation projects >> ?> were, are and will be the one-man ones. >> >> ?Joining a team in a gathering group like Launchpad translators, will >> ?(if you get the team of the ground) allow you to get help with the >> ?proofreading, turning it into an at least 2 man job. I have >> ?contributed to jmol, rednotebook, Ubuntu Pay and others in this way me >> ?translating and someone else proofreading or the other way around and >> ?it works just fine. > I am KDE and Fedora coordinator and Opera Software official volunteer > translator. For sure, I cannot understand what prevents you from doing this > now. Just call your reviewers and they correct the mistakes. > > Do you want to ban some "bad" guys that ruined your translations? That is > easy, file a question on LP. ;) Not a bad guy, but simply one that isn't as good at grammar and yes I want to do that and no it isn't easy. To ensure that the translations I did had proofread etc. and were thorough with, keeps being that way, then I will have to continuously scan all my old translations for bad contributions, then correct them back, maybe try and contact the bad contributor by email to make sure that he wont keep making the same bad suggestions and if he wont respond what? Eventually file a questions in LP and ask to have him banned from translation? That's easy? >> ?> Idea of creation of so called >> ?> 'translation groups' ?maybe could be useful for some projects, >> ?> however, is totally senseless in the Scilab case. Actually it adds >> ?> nothing to the quality of translation of Scilab or even decrease it >> ?> because it kills effort of causal translators which help us by >> ?> correction of one or two strings only. >> >> ?You can't do proper QA by a casual effort. > > Why? I believe that not all of us are professionals in translation. Why > casual reviewer (we are all casual reviewers) cannot fix casual translator > (do not tell me that you will leave forever and translate Scilab to the end > of times)? I did not mean casual as supposed to professional. I was referring to the case described _just_ above, about someone casually dropping by and fixing a couple of errors in the translations. >> ?> These people need to have easy >> ?> and simple access to the translation interface, otherwise they simply >> ?> will not participate in the translation process. >> >> ?Making translations something that you can contribute to with this >> ?kind of hit-and-run contributions is a huge mistake. I don't know who >> ?ever came up with that idea but it is horrible. Translations, just >> ?like programming or documentations writing, requires a little more >> ?effort that that to do it right. That was the way the Launchpad >> ?started out and they have now realized that effect that has on quality >> ?and therefore now, still allow it, but recommends restrictions after >> ?the upstart phase >> > Well, who can judge who are right 3 Ubuntu translators or 3 KDE translators? > > There are no conflicts between Scilab translators. We were working together > to make the translations better. But then someone find that we should not > give the opportunity to the new translators and reviewers and it appears > that there are groups of translators (lp-translators) that know things > better but did not translate Scilab because of the wrong rules All I can tell you is that a decision has been made to restrict access to translations to pretty much all major free software projects (a lot more that 3 translators). And yes, giving people the options to implement QA properly in the translations did play a role in those decisions. >> ?> I know examples of the projects with completely restrict-less access >> ?> to the translation interface which are extremely successful. See for >> ?> example SMath Studio (freeware Mathcad clone) translation interface at >> ?> >> ?> http://smath.info/translator/ >> >> ?Success in terms of what? Quantity I'll believe, quality, not likely. > > Can you give an example of the faulty translation? I see bad suggestions all the time. Luckily the are in translations the are restricted so they did not just get implemented directly. You want me to find you a couple of suggestions and explain to you why they are bad Danish translations? Regards Kenneth From k.nielsen81 at gmail.com Fri May 6 13:49:57 2011 From: k.nielsen81 at gmail.com (Kenneth Nielsen) Date: Fri, 6 May 2011 13:49:57 +0200 Subject: [Scilab-loc] Re: Settings for the scilab localization inLaunchPadTranslations In-Reply-To: <1304677815.3302.102.camel@losinj.inria.fr> References: <1304501612.1263.127.camel@korcula.inria.fr> <1304673190.3302.59.camel@losinj.inria.fr> <1304677815.3302.102.camel@losinj.inria.fr> Message-ID: >> Well, since there is a Danish team in launchpad translators Structures >> or Restricted wont make a bit of difference for me. Lets just make >> sure we all understand what the difference is, see some of my other >> mails. > OK, Danish is OK but as far as I know, some lp teams are empty. Yes, that is also one of the reasons why we are trying to rally some people behind this group. >> >> > If you are still not sure, please create "Scilab translators" and approve >> >> > its members by yourself >> >> >> >> That is the next best solution. This will allow me the control I need >> >> in order for med to contribute. >> > >> > OK. I like this potential good solution. Any one has an objection for >> > this solution ? >> >> Well as I wrote above, unnecessary bureaucracy is also one of the >> criteria that I use to select projects that I want to contribute to. > For now, it is what we have, you just need a lp account to contribute to > it. And join a team and possible an email list and get my proofreader to join the team just for the sake of proofreading... I'm not saying it's to much work, I'm just saying it's more bureaucracy. >> However, before you make such a change you should understand how it >> will work. The following will happen. Common for restricted and >> structured is that if you do assign a team or person within that group >> to the translations into a language, then it will be restricted to >> that team or person (so people casually dropping by cannot >> contribute). If you don't assign a person or team to the translation >> into a language, then the translation into that language will be open >> to all. If you make it a policy not assign anybody to the languages >> and use structured then the result is the same as open, and you might >> as well keep that. > > OK, thanks for the explanations. > So, a thing I could do could be to try to chat active people (or > identifying them). Chat with them if they agree to join/create a team. > If they are OK, let's go for it. Otherwise, I don't not assign any team > and leave it like now. > > How does it sound ? Well, that would be fine by me (although more bureaucracy). But I am unsure if the rest here will agree with it, because they value the options for people to contribute without being part of the team. If you do this, and e.g. assign the Croatian translation to Yuri, then only he will be able to contribute to it. No other Croatians that just happens to drop by. So I don't know if that is ok. In any case it seems that you guys have a good thing going here and I don't want to mess that up. I'm just throwing around some ideas, so now you can decide if you want to make a change and then afterwards I will decide if I can contribute. Best Regards Kenneth Nielsen From rokach at tu.kielce.pl Fri May 6 13:52:29 2011 From: rokach at tu.kielce.pl (Ihor Rokach) Date: Fri, 6 May 2011 13:52:29 +0200 Subject: [Scilab-loc] Re: Settings for the scilab localization inLaunchPadTranslations In-Reply-To: <1304673190.3302.59.camel@losinj.inria.fr> References: <1304501612.1263.127.camel@korcula.inria.fr> <"BANLkTimARd_M=OX7okKpKeW yEA3FWWxQYA"@mail.gmail.com> <1304673190.3302.59.camel@losinj.inria.fr> Message-ID: > > > If you are still not sure, please create "Scilab translators" and > approve > > > its members by yourself > > > > That is the next best solution. This will allow me the control I need > > in order for med to contribute. > OK. I like this potential good solution. Any one has an objection for > this solution ? I think we need ANY solution just now (due to the forthcoming release of Scilab). After some testing we may change it. "Scilab translators" is a good compromise. Anyway, Scilab is just another language, a bit more simple than English or Chinese:-) From yurchor at ukr.net Fri May 6 16:12:54 2011 From: yurchor at ukr.net (Yuri Chornoivan) Date: Fri, 6 May 2011 07:12:54 -0700 (PDT) Subject: Settings for the scilab localization in LaunchPad Translations In-Reply-To: References: <1304501612.1263.127.camel@korcula.inria.fr> Message-ID: ???????? Fri, 06 May 2011 14:42:37 +0300, Kenneth Nielsen [via Scilab / Xcos - Mailing Lists Archives] : > > > 2011/5/6 Yuri Chornoivan : >>> 2011/5/5 Ihor Rokach <[hidden email]>: >>> > Yuri, >>> > >>> > I agree with you totally. Most of the Open Source translation >>> projects >>> > were, are and will be the one-man ones. >>> >>> Joining a team in a gathering group like Launchpad translators, will >>> (if you get the team of the ground) allow you to get help with the >>> proofreading, turning it into an at least 2 man job. I have >>> contributed to jmol, rednotebook, Ubuntu Pay and others in this way me >>> translating and someone else proofreading or the other way around and >>> it works just fine. >> I am KDE and Fedora coordinator and Opera Software official volunteer >> translator. For sure, I cannot understand what prevents you from doing >> this >> now. Just call your reviewers and they correct the mistakes. >> >> Do you want to ban some "bad" guys that ruined your translations? That >> is >> easy, file a question on LP. ;) > > Not a bad guy, but simply one that isn't as good at grammar and yes I > want to do that and no it isn't easy. To ensure that the translations > I did had proofread etc. and were thorough with, keeps being that way, > then I will have to continuously scan all my old translations for bad > contributions, then correct them back, maybe try and contact the bad > contributor by email to make sure that he wont keep making the same > bad suggestions and if he wont respond what? Eventually file a > questions in LP and ask to have him banned from translation? That's > easy? Thus, you, who do not love bureaucracy decided to ban any possible contributor a priori? As you know if there is no lp-translators team with "Restricted" permissions it is not even possible to make even suggestions. Are you sure that potential contributor love bureaucracy more than you? What if you lose the interest (you have already said that Octave is completer [1])? Who can stand all this bureaucracy if your team of 5 members become stale? Who will prove that you and your reviewer are "good guys", not the first people who have registered the group first? Suppose that our fictitious brave new translator decided to "revive" the group. Who can guarantee that he or she obtain the answer before giving up and going to translate something else? For example, my question [2] is still unanswered, though I asked Canonical personnel to support it [3]. [1] http://logs.ubuntu-eu.org/free/2011/04/26/%23ubuntu-translators.html [2] https://answers.launchpad.net/launchpad/+question/155900 [3] http://logs.ubuntu-eu.org/free/2011/05/04/%23ubuntu-translators.html > >>> > Idea of creation of so called >>> > 'translation groups' maybe could be useful for some projects, >>> > however, is totally senseless in the Scilab case. Actually it adds >>> > nothing to the quality of translation of Scilab or even decrease it >>> > because it kills effort of causal translators which help us by >>> > correction of one or two strings only. >>> >>> You can't do proper QA by a casual effort. >> >> Why? I believe that not all of us are professionals in translation. Why >> casual reviewer (we are all casual reviewers) cannot fix casual >> translator >> (do not tell me that you will leave forever and translate Scilab to the >> end >> of times)? > > I did not mean casual as supposed to professional. I was referring to > the case described _just_ above, about someone casually dropping by > and fixing a couple of errors in the translations. > It is the bug in Launchpad/Rosetta itself. If developers cannot implement this (the bug is well-known) why you are sure that we should use workarounds? >>> > These people need to have easy >>> > and simple access to the translation interface, otherwise they >>> simply >>> > will not participate in the translation process. >>> >>> Making translations something that you can contribute to with this >>> kind of hit-and-run contributions is a huge mistake. I don't know who >>> ever came up with that idea but it is horrible. Translations, just >>> like programming or documentations writing, requires a little more >>> effort that that to do it right. That was the way the Launchpad >>> started out and they have now realized that effect that has on quality >>> and therefore now, still allow it, but recommends restrictions after >>> the upstart phase >>> >> Well, who can judge who are right 3 Ubuntu translators or 3 KDE >> translators? >> >> There are no conflicts between Scilab translators. We were working >> together >> to make the translations better. But then someone find that we should >> not >> give the opportunity to the new translators and reviewers and it appears >> that there are groups of translators (lp-translators) that know things >> better but did not translate Scilab because of the wrong rules > > > All I can tell you is that a decision has been made to restrict access > to translations to pretty much all major free software projects (a lot > more that 3 translators). And yes, giving people the options to > implement QA properly in the translations did play a role in those > decisions. I try and remove such restrictions from any project I am taking part (KDE, GNOME, TP, Fedora). People should not suffer from the bad management of their teams or bottlenecks in translator-editor-commiter chain. After all, as I can see all such restrictions leads to one end. See Slovak translation case in GNOME [4]. QA arguments do not help. [4] http://mail.gnome.org/archives/gnome-i18n/2010-May/msg00023.html > >>> > I know examples of the projects with completely restrict-less access >>> > to the translation interface which are extremely successful. See for >>> > example SMath Studio (freeware Mathcad clone) translation interface >>> at >>> > >>> > http://smath.info/translator/ >>> >>> Success in terms of what? Quantity I'll believe, quality, not likely. >> >> Can you give an example of the faulty translation? > > I see bad suggestions all the time. Luckily the are in translations > the are restricted so they did not just get implemented directly. You > want me to find you a couple of suggestions and explain to you why > they are bad Danish translations? > > Regards Kenneth It was said ?Do not judge, or you too will be judged. For in the same way you judge others, you will be judged, and with the measure you use, it will be measured to you. I only want to second this. Best regards, Yuri -- View this message in context: http://mailinglists.scilab.org/Settings-for-the-scilab-localization-in-LaunchPad-Translations-tp2870916p2908319.html Sent from the Scilab localization - Mailing Lists Archives mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From k.nielsen81 at gmail.com Mon May 9 16:13:26 2011 From: k.nielsen81 at gmail.com (Kenneth Nielsen) Date: Mon, 9 May 2011 16:13:26 +0200 Subject: [Scilab-loc] Re: Settings for the scilab localization in LaunchPad Translations In-Reply-To: References: <1304501612.1263.127.camel@korcula.inria.fr> Message-ID: >> Not a bad guy, but simply one that isn't as good at grammar and yes I >> want to do that and no it isn't easy. To ensure that the translations >> I did had proofread etc. and were thorough with, keeps being that way, >> then I will have to continuously scan all my old translations for bad >> contributions, then correct them back, maybe try and contact the bad >> contributor by email to make sure that he wont keep making the same >> bad suggestions and if he wont respond what? Eventually file a >> questions in LP and ask to have him banned from translation? That's >> easy? > Thus, you, who do not love bureaucracy decided to ban any possible > contributor a priori? No. I just require them to do a little more work than can be accomplished in 3 minutes with a hit-and-run translations contribution. > As you know if there is no lp-translators team with > "Restricted" permissions it is not even possible to make even suggestions. > Are you sure that potential contributor love bureaucracy more than you? The process of starting a team under lp translators is done only once and can be used for many projects, so on an overall scale this will amount to less bureaucracy than having a group per project, which is what I was comparing to. > What if you lose the interest (you have already said that Octave is > completer [1])? That is perhaps a somewhat selective interpretation of what I said. > Who can stand all this bureaucracy if your team of 5 > members become stale? Who will prove that you and your reviewer are "good > guys", not the first people who have registered the group first? No-one, for the last and final time. These measures do not guarantee translations quality, but the fo provide the tools necessary to make it happen > Suppose that our fictitious brave new translator decided to "revive" the > group. Who can guarantee that he or she obtain the answer before giving up > and going to translate something else? For example, my question [2] is > still unanswered, though I asked Canonical personnel to support it [3]. > > [1] http://logs.ubuntu-eu.org/free/2011/04/26/%23ubuntu-translators.html > [2] https://answers.launchpad.net/launchpad/+question/155900 > [3] http://logs.ubuntu-eu.org/free/2011/05/04/%23ubuntu-translators.html See above >>>> ?> Idea of creation of so called >>>> ?> 'translation groups' ?maybe could be useful for some projects, >>>> ?> however, is totally senseless in the Scilab case. Actually it adds >>>> ?> nothing to the quality of translation of Scilab or even decrease it >>>> ?> because it kills effort of causal translators which help us by >>>> ?> correction of one or two strings only. >>>> >>>> ?You can't do proper QA by a casual effort. >>> >>> Why? I believe that not all of us are professionals in translation. Why >>> casual reviewer (we are all casual reviewers) cannot fix casual >>> translator >>> (do not tell me that you will leave forever and translate Scilab to the >>> end >>> of times)? >> >> I did not mean casual as supposed to professional. I was referring to >> the case described _just_ above, about someone casually dropping by >> and fixing a couple of errors in the translations. >> > It is the bug in Launchpad/Rosetta itself. If developers cannot implement > this (the bug is well-known) why you are sure that we should use > workarounds? I'm not 100% sure I understand what you mean. The way we implement QA in launchpad is the recommended way to do it, if you want to, it is not a workaround. >>>> ?> These people need to have easy >>>> ?> and simple access to the translation interface, otherwise they >>>> simply >>>> ?> will not participate in the translation process. >>>> >>>> ?Making translations something that you can contribute to with this >>>> ?kind of hit-and-run contributions is a huge mistake. I don't know who >>>> ?ever came up with that idea but it is horrible. Translations, just >>>> ?like programming or documentations writing, requires a little more >>>> ?effort that that to do it right. That was the way the Launchpad >>>> ?started out and they have now realized that effect that has on quality >>>> ?and therefore now, still allow it, but recommends restrictions after >>>> ?the upstart phase >>>> >>> Well, who can judge who are right 3 Ubuntu translators or 3 KDE >>> translators? >>> >>> There are no conflicts between Scilab translators. We were working >>> together >>> to make the translations better. But then someone find that we should >>> not >>> give the opportunity to the new translators and reviewers and it appears >>> that there are groups of translators (lp-translators) that know things >>> better but did not translate Scilab because of the wrong rules >> >> >> All I can tell you is that a decision has been made to restrict access >> to translations to pretty much all major free software projects (a lot >> more that 3 translators). And yes, giving people the options to >> implement QA properly in the translations did play a role in those >> decisions. > I try and remove such restrictions from any project I am taking part (KDE, > GNOME, TP, Fedora). People should not suffer from the bad management of > their teams or bottlenecks in translator-editor-commiter chain. > > After all, as I can see all such restrictions leads to one end. See Slovak > translation case in GNOME [4]. QA arguments do not help. So what if people run into problems. Making good stuff is difficult, nothing to do about that. Free software projects are always understaffed. In my view, what you are doing is to adopt an inferior work flow, merely because you have concluded that we don't have the resources to implement a proper one. That is not something I would do. > [4] http://mail.gnome.org/archives/gnome-i18n/2010-May/msg00023.html > >> >>>> ?> I know examples of the projects with completely restrict-less access >>>> ?> to the translation interface which are extremely successful. See for >>>> ?> example SMath Studio (freeware Mathcad clone) translation interface >>>> at >>>> ?> >>>> ?> http://smath.info/translator/ >>>> >>>> ?Success in terms of what? Quantity I'll believe, quality, not likely. >>> >>> Can you give an example of the faulty translation? >> >> I see bad suggestions all the time. Luckily the are in translations >> the are restricted so they did not just get implemented directly. You >> want me to find you a couple of suggestions and explain to you why >> they are bad Danish translations? >> >> Regards Kenneth > It was said > > ?Do not judge, or you too will be judged. For in the same way you judge > others, you will be judged, and with the measure you use, it will be > measured to you. > > I only want to second this. Judge? About bad grammar, spelling mistakes and failure to implement a common vocabulary across applications? Guilty as charged! And I certainly hope that someone will "judge" me too. In fact they do, and I rely on them to do so, because I also make mistakes when I translate. Don't be mistaken about that. When I talk about just how many bad translations and errors we catch with proofreading, I know that both from doing the proofreading and from having my own stuff proofread. The difference is that I actually care enough about people learning something along the way, to not just correct their stuff without including them in the process. Something that is not always possible with open permissions. In any case, I don't think you and I are going to see eye to eye on this thing. So why don't you guys, the existing community around Scilab translations, decide what, if any, change you want to make, and then I'll check in later* to see if I can contribute to the project or not. \Kenneth * I'll be insanely busy until the end of August anyway, so I probably wont make much progress on the translation in the mean time. I just wanted get the discussion going. From yurchor at ukr.net Mon May 9 17:36:05 2011 From: yurchor at ukr.net (Yuri Chornoivan) Date: Mon, 9 May 2011 08:36:05 -0700 (PDT) Subject: Settings for the scilab localization in LaunchPad Translations In-Reply-To: References: <1304501612.1263.127.camel@korcula.inria.fr> Message-ID: ???????? Mon, 09 May 2011 17:13:32 +0300, Kenneth Nielsen [via Scilab / Xcos - Mailing Lists Archives] : > > >>> Not a bad guy, but simply one that isn't as good at grammar and yes I >>> want to do that and no it isn't easy. To ensure that the translations >>> I did had proofread etc. and were thorough with, keeps being that way, >>> then I will have to continuously scan all my old translations for bad >>> contributions, then correct them back, maybe try and contact the bad >>> contributor by email to make sure that he wont keep making the same >>> bad suggestions and if he wont respond what? Eventually file a >>> questions in LP and ask to have him banned from translation? That's >>> easy? >> Thus, you, who do not love bureaucracy decided to ban any possible >> contributor a priori? > > No. I just require them to do a little more work than can be > accomplished in 3 minutes with a hit-and-run translations > contribution. > Do you seriously think that this 3 minutes work will be reviewed in a reasonable time and this review can lead to some well-defined conclusions? What if the review will come in a month or two? What if it will never come at all? >> As you know if there is no lp-translators team with >> "Restricted" permissions it is not even possible to make even >> suggestions. >> Are you sure that potential contributor love bureaucracy more than you? > > The process of starting a team under lp translators is done only once > and can be used for many projects, so on an overall scale this will > amount to less bureaucracy than having a group per project, which is > what I was comparing to. > Before your input there was no such idea at all. And I do not think that it will lead to less bureaucracy. You just replace Launchpad Translations Coordinators by yourself. And it's not the fact that waiting for your or mine approval for a month or two is better than waiting for LTC approval for a month or two [1]. It was not very kind to ban more than half of Scilab translators just to give lp-translators another dozen of groups in a few months. [1] https://answers.launchpad.net/launchpad/+question/153416 >> What if you lose the interest (you have already said that Octave is >> completer [1])? > > That is perhaps a somewhat selective interpretation of what I said. > Maybe. I was just an example. In a small teams probability of such cases is almost equal to 1. >> Who can stand all this bureaucracy if your team of 5 >> members become stale? Who will prove that you and your reviewer are >> "good >> guys", not the first people who have registered the group first? > > No-one, for the last and final time. These measures do not guarantee > translations quality, but the fo provide the tools necessary to make > it happen > That is very interesting point. Can you guide me to the page with *tools* of lp-translators. I have always preferred offline TM and strict glossary with pology [2] checks and did not know about specific LP tools. If no-one can guarantee anything and there is no mailing list where you can claim the change of group leader I think that LP-groups are very dangerous regarding to the quality and standards. >> Suppose that our fictitious brave new translator decided to "revive" the >> group. Who can guarantee that he or she obtain the answer before giving >> up >> and going to translate something else? For example, my question [2] is >> still unanswered, though I asked Canonical personnel to support it [3]. >> >> [1] http://logs.ubuntu-eu.org/free/2011/04/26/%23ubuntu-translators.html >> [2] https://answers.launchpad.net/launchpad/+question/155900 >> [3] http://logs.ubuntu-eu.org/free/2011/05/04/%23ubuntu-translators.html > > See above > >>>>> > Idea of creation of so called >>>>> > 'translation groups' maybe could be useful for some projects, >>>>> > however, is totally senseless in the Scilab case. Actually it adds >>>>> > nothing to the quality of translation of Scilab or even decrease >>>>> it >>>>> > because it kills effort of causal translators which help us by >>>>> > correction of one or two strings only. >>>>> >>>>> You can't do proper QA by a casual effort. >>>> >>>> Why? I believe that not all of us are professionals in translation. >>>> Why >>>> casual reviewer (we are all casual reviewers) cannot fix casual >>>> translator >>>> (do not tell me that you will leave forever and translate Scilab to >>>> the >>>> end >>>> of times)? >>> >>> I did not mean casual as supposed to professional. I was referring to >>> the case described _just_ above, about someone casually dropping by >>> and fixing a couple of errors in the translations. >>> >> It is the bug in Launchpad/Rosetta itself. If developers cannot >> implement >> this (the bug is well-known) why you are sure that we should use >> workarounds? > > I'm not 100% sure I understand what you mean. The way we implement QA > in launchpad is the recommended way to do it, if you want to, it is > not a workaround. > I meant that trying to make interface uncluttered and simplistic, developers removed (or did not implement) filtering translations by translators, like in Transifex. It leads to the two-level workflow with suggestions. Moreover, LP does not remove wrong suggestions from TM and make things even worse. >>>>> > These people need to have easy >>>>> > and simple access to the translation interface, otherwise they >>>>> simply >>>>> > will not participate in the translation process. >>>>> >>>>> Making translations something that you can contribute to with this >>>>> kind of hit-and-run contributions is a huge mistake. I don't know >>>>> who >>>>> ever came up with that idea but it is horrible. Translations, just >>>>> like programming or documentations writing, requires a little more >>>>> effort that that to do it right. That was the way the Launchpad >>>>> started out and they have now realized that effect that has on >>>>> quality >>>>> and therefore now, still allow it, but recommends restrictions after >>>>> the upstart phase >>>>> >>>> Well, who can judge who are right 3 Ubuntu translators or 3 KDE >>>> translators? >>>> >>>> There are no conflicts between Scilab translators. We were working >>>> together >>>> to make the translations better. But then someone find that we should >>>> not >>>> give the opportunity to the new translators and reviewers and it >>>> appears >>>> that there are groups of translators (lp-translators) that know things >>>> better but did not translate Scilab because of the wrong rules >>> >>> >>> All I can tell you is that a decision has been made to restrict access >>> to translations to pretty much all major free software projects (a lot >>> more that 3 translators). And yes, giving people the options to >>> implement QA properly in the translations did play a role in those >>> decisions. >> I try and remove such restrictions from any project I am taking part >> (KDE, >> GNOME, TP, Fedora). People should not suffer from the bad management of >> their teams or bottlenecks in translator-editor-commiter chain. >> >> After all, as I can see all such restrictions leads to one end. See >> Slovak >> translation case in GNOME [4]. QA arguments do not help. > > So what if people run into problems. Making good stuff is difficult, > nothing to do about that. Free software projects are always > understaffed. In my view, what you are doing is to adopt an inferior > work flow, merely because you have concluded that we don't have the > resources to implement a proper one. That is not something I would do. > KDE and GNOME have the rules to handle these problems (see the cited case). If your statement about the number of translators is right why the recommended LP-translators way is trying to make the new translator's life difficult? Personally, I am very happy that these "recommendations" are implemented just for a few projects only (Chromium, SuperTuxKart). I must thank the developers of JMol, Stellarium, Avogadro, OpenShot, Deja Dup and many others for not changing to "Restricted". If they have changed the policy as it was "recommended" there are no Ukrainian translation for these tools at all. >> [4] http://mail.gnome.org/archives/gnome-i18n/2010-May/msg00023.html >> >>> >>>>> > I know examples of the projects with completely restrict-less >>>>> access >>>>> > to the translation interface which are extremely successful. See >>>>> for >>>>> > example SMath Studio (freeware Mathcad clone) translation >>>>> interface >>>>> at >>>>> > >>>>> > http://smath.info/translator/ >>>>> >>>>> Success in terms of what? Quantity I'll believe, quality, not >>>>> likely. >>>> >>>> Can you give an example of the faulty translation? >>> >>> I see bad suggestions all the time. Luckily the are in translations >>> the are restricted so they did not just get implemented directly. You >>> want me to find you a couple of suggestions and explain to you why >>> they are bad Danish translations? >>> >>> Regards Kenneth >> It was said >> >> ?Do not judge, or you too will be judged. For in the same way you judge >> others, you will be judged, and with the measure you use, it will be >> measured to you. >> >> I only want to second this. > > Judge? About bad grammar, spelling mistakes and failure to implement a > common vocabulary across applications? Guilty as charged! And I > certainly hope that someone will "judge" me too. In fact they do, and > I rely on them to do so, because I also make mistakes when I > translate. Don't be mistaken about that. When I talk about just how > many bad translations and errors we catch with proofreading, I know > that both from doing the proofreading and from having my own stuff > proofread. The difference is that I actually care enough about people > learning something along the way, to not just correct their stuff > without including them in the process. Something that is not always > possible with open permissions. LP just do not show them the glossary like it is implemented for offline tools (Lokalize, Virtaal). Moreother, at least for my language Ubuntu-translators recommendations are inconsistent with Microsoft, GNOME and KDE guidelines, as well as current Ukrainian orthography rules. Recommendations for Georgian are wrong for replacers (%(something)s), recommendations for Russian contain visible typos, etc. And Ubuntu-translators team is a core of the most LP-translators teams. Who are the judges? Can they be judged? ;) Bad grammar, spelling mistakes, and failure to implement a common vocabulary across applications? In Scilab? Are you sure that a grammar knowledge, not a knowledge of mathematics is a best friend here? > > In any case, I don't think you and I are going to see eye to eye on > this thing. So why don't you guys, the existing community around > Scilab translations, decide what, if any, change you want to make, and > then I'll check in later* to see if I can contribute to the project or > not. > > \Kenneth > > * I'll be insanely busy until the end of August anyway, so I probably > wont make much progress on the translation in the mean time. I just > wanted get the discussion going. -- View this message in context: http://mailinglists.scilab.org/Settings-for-the-scilab-localization-in-LaunchPad-Translations-tp2870916p2919195.html Sent from the Scilab localization - Mailing Lists Archives mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From k.nielsen81 at gmail.com Tue May 10 10:38:28 2011 From: k.nielsen81 at gmail.com (Kenneth Nielsen) Date: Tue, 10 May 2011 10:38:28 +0200 Subject: [Scilab-loc] Re: Settings for the scilab localization in LaunchPad Translations In-Reply-To: References: <1304501612.1263.127.camel@korcula.inria.fr> Message-ID: 2011/5/9 Yuri Chornoivan : > ???????? Mon, 09 May 2011 17:13:32 +0300, Kenneth Nielsen [via Scilab / > Xcos - Mailing Lists Archives] > <[hidden email]>: > >> >> >>>> Not a bad guy, but simply one that isn't as good at grammar and yes I >>>> want to do that and no it isn't easy. To ensure that the translations >>>> I did had proofread etc. and were thorough with, keeps being that way, >>>> then I will have to continuously scan all my old translations for bad >>>> contributions, then correct them back, maybe try and contact the bad >>>> contributor by email to make sure that he wont keep making the same >>>> bad suggestions and if he wont respond what? Eventually file a >>>> questions in LP and ask to have him banned from translation? That's >>>> easy? >>> Thus, you, who do not love bureaucracy decided to ban any possible >>> contributor a priori? >> >> No. I just require them to do a little more work than can be >> accomplished in 3 minutes with a hit-and-run translations >> contribution. >> > Do you seriously think that this 3 minutes work will be reviewed in a > reasonable time and this review can lead to some well-defined conclusions? Yes > What if the review will come in a month or two? What if it will never come > at all? Provided the contributor has made contact with the team, so they know about the contribution, then it is about the priorities of that team when the person gets the review. What if it never happens? Well, as I have already said, more than once, I personally would rather have fewer translations of better quality. >>> As you know if there is no lp-translators team with >>> "Restricted" permissions it is not even possible to make even >>> suggestions. >>> Are you sure that potential contributor love bureaucracy more than you? >> >> The process of starting a team under lp translators is done only once >> and can be used for many projects, so on an overall scale this will >> amount to less bureaucracy than having a group per project, which is >> what I was comparing to. >> > Before your input there was no such idea at all. Maybe not in Scilab circles, but it has certainly been around. As I have also mentioned at least a couple of times already, this is actually the LP recommended way for independent projects past the startup phase. > And I do not think that it will lead to less bureaucracy. You just replace > Launchpad Translations Coordinators by yourself. And it's not the fact > that waiting for your or mine approval for a month or two is better than > waiting for LTC approval for a month or two [1]. If the purpose is to implement a controlled proofreading workflow. Then yes, it will certainly create less bureaucracy having a shared group for all the independent projects compared to one group per project. > It was not very kind to ban more than half of Scilab translators just to > give lp-translators another dozen of groups in a few months. That is not the result of what I am proposing, please stop putting words in my mouth. > [1] https://answers.launchpad.net/launchpad/+question/153416 > >>> What if you lose the interest (you have already said that Octave is >>> completer [1])? >> >> That is perhaps a somewhat selective interpretation of what I said. >> > > Maybe. I was just an example. In a small teams probability of such cases > is almost equal to 1. It can happen, yes. But with a probability of 1, hardly. >>> Who can stand all this bureaucracy if your team of 5 >>> members become stale? Who will prove that you and your reviewer are >>> "good >>> guys", not the first people who have registered the group first? >> >> No-one, for the last and final time. These measures do not guarantee >> translations quality, but the fo provide the tools necessary to make >> it happen > > That is very interesting point. Can you guide me to the page with *tools* > of lp-translators. I have always preferred offline TM and strict glossary > with pology [2] checks and did not know about specific LP tools. I have used that expression many times before in this discussion. With "the tools necessary to implement the workflow" I am referring to having control over the translations and functionality for proofreading. > If no-one can guarantee anything and there is no mailing list where you > can claim the change of group leader I think that LP-groups are very > dangerous regarding to the quality and standards. If the first persons that arrive have bad intentions or are sloppy, then you will have lost no matter what. We have already had our share or disasters back when all translations were open be default. But why I don't understand is why you think that is different from what you do now, if you have only person per language, no one among you knows anything about the quality of the translations into the other languages, so you are also just trusting the first (and in this case only) person that arrived. >>> It is the bug in Launchpad/Rosetta itself. If developers cannot >>> implement >>> this (the bug is well-known) why you are sure that we should use >>> workarounds? >> >> I'm not 100% sure I understand what you mean. The way we implement QA >> in launchpad is the recommended way to do it, if you want to, it is >> not a workaround. >> > I meant that trying to make interface uncluttered and simplistic, > developers removed (or did not implement) filtering translations by > translators, like in Transifex. It leads to the two-level workflow with > suggestions. Moreover, LP does not remove wrong suggestions from TM and > make things even worse. - It is possible to filter translations by contributor (all though not directly in the translation interface). But often enough it is enough to simply filter by new suggestions. - You can also dismiss wrong suggestions. - Suggestions enter the TM the moment that it has been suggested and does not disappear from there if you dismiss the suggestion. However, when you are offered the string, you will be offered information about whether the string has been used somewhere else or is just a suggestions. >> So what if people run into problems. Making good stuff is difficult, >> nothing to do about that. Free software projects are always >> understaffed. In my view, what you are doing is to adopt an inferior >> work flow, merely because you have concluded that we don't have the >> resources to implement a proper one. That is not something I would do. >> > KDE and GNOME have the rules to handle these problems (see the cited > case). If your statement about the number of translators is right why the > recommended LP-translators way is trying to make the new translator's life > difficult? > > Personally, I am very happy that these "recommendations" are implemented > just for a few projects only (Chromium, SuperTuxKart). I must thank the > developers of JMol, Stellarium, Avogadro, OpenShot, Deja Dup and many > others for not changing to "Restricted". If they have changed the policy > as it was "recommended" there are no Ukrainian translation for these tools > at all. What is with the "restricted" I have never said that it is the recommendation that it should be restricted. I have said that it is the LP recommendation that it should be "structured" or "restricted" when the projects is through the start up phase. And I have said that I personally, if I was a coordinator of a project would prefer "restricted", but as far as giving me the tools that need for translating projects, structured is enough. >>>> I see bad suggestions all the time. Luckily the are in translations >>>> the are restricted so they did not just get implemented directly. You >>>> want me to find you a couple of suggestions and explain to you why >>>> they are bad Danish translations? >>>> >>>> Regards Kenneth >>> It was said >>> >>> ?Do not judge, or you too will be judged. For in the same way you judge >>> others, you will be judged, and with the measure you use, it will be >>> measured to you. >>> >>> I only want to second this. >> >> Judge? About bad grammar, spelling mistakes and failure to implement a >> common vocabulary across applications? Guilty as charged! And I >> certainly hope that someone will "judge" me too. In fact they do, and >> I rely on them to do so, because I also make mistakes when I >> translate. Don't be mistaken about that. When I talk about just how >> many bad translations and errors we catch with proofreading, I know >> that both from doing the proofreading and from having my own stuff >> proofread. The difference is that I actually care enough about people >> learning something along the way, to not just correct their stuff >> without including them in the process. Something that is not always >> possible with open permissions. > LP just do not show them the glossary like it is implemented for offline > tools (Lokalize, Virtaal). Yeah that would be a nice feature, but until then, we make do with having it on another internet page and encourage translators to gather around a email list where where you will know about the glossary. > Moreother, at least for my language > Ubuntu-translators recommendations are inconsistent with Microsoft, GNOME > and KDE guidelines, This is a special case that is often discussed. In this case there is no right or wrong. Unifying glossary across all large projects would be nice but it is not always possible. as well as current Ukrainian orthography rules. > Recommendations for Georgian are wrong for replacers (%(something)s), > recommendations for Russian contain visible typos, etc. And > Ubuntu-translators team is a core of the most LP-translators teams. Who > are the judges? Can they be judged? ;) So you are using the fact that these bad guidelines exits as an argument not to have any at all? How to fix these problems, well we do the same thing we always do in free software, we form groups, that communicate, and discuss the problems. > Bad grammar, spelling mistakes, and failure to implement a common > vocabulary across applications? In Scilab? Are you sure that a grammar > knowledge, not a knowledge of mathematics is a best friend here? I was speaking about all projects in general, which should be pretty clear from the context. For very technical programs it is off course an extra requirement with some technical knowledge. However, I maintain that it is still very important. One of the most common corrections during our proofreading is one of simple stile. It seems that it is very easy for translators to get stuck with the English sentence structure when you are actually translating it, and this sentence structure might not be the natural one to use in the other language. However, it seems that it is far more easy for the proofreader to ignore the English string and simple see if the string is good e.g. Danish. In these cases there is no right or wrong, and therefore the corrections will often just be suggestions for an alternative formulation. However the results of not doing it, is to have a lot of Danish strings with English sentence structure in the translation. So yes, this, along with grammar and spelling is very important for leaving the user a professional impression of the program. Regards Kenneth >> In any case, I don't think you and I are going to see eye to eye on >> this thing. So why don't you guys, the existing community around >> Scilab translations, decide what, if any, change you want to make, and >> then I'll check in later* to see if I can contribute to the project or >> not. >> >> \Kenneth >> >> * I'll be insanely busy until the end of August anyway, so I probably >> wont make much progress on the translation in the mean time. I just >> wanted get the discussion going. > > ________________________________ > View this message in context: Re: Settings for the scilab localization in > LaunchPad Translations > Sent from the Scilab localization - Mailing Lists Archives mailing list > archive at Nabble.com. > From yurchor at ukr.net Wed May 11 12:18:27 2011 From: yurchor at ukr.net (Yuri Chornoivan) Date: Wed, 11 May 2011 03:18:27 -0700 (PDT) Subject: Context for Scilab messages Message-ID: <1305109107682-2926701.post@n3.nabble.com> Hi! The messages in the current Scilab localization files are sorted alphabetically that sometimes lead to puzzles where different part of the same message are scattered through the big translation file. The comments in PO file will be the good hint in these cases, but they are regretfully not shown neither in Rosetta, nor in offline editors due to the extra #-line. Example: # # File: macros/Sources/tkscaleblk.sci, line: 49 msgid "&File" msgstr "" # # File: macros/Sources/tkscaleblk.sci, line: 50 msgid "&Tools" msgstr "" Should be: # File: macros/Sources/tkscaleblk.sci, line: 49 msgid "&File" msgstr "" # File: macros/Sources/tkscaleblk.sci, line: 50 msgid "&Tools" msgstr "" The question: Is it worth to change the extraction script accordingly? Can it be changed? Thanks in advance for your answers. Best regards, Yuri -- View this message in context: http://mailinglists.scilab.org/Context-for-Scilab-messages-tp2926701p2926701.html Sent from the Scilab localization - Mailing Lists Archives mailing list archive at Nabble.com. From sylvestre.ledru at scilab.org Wed May 11 12:49:51 2011 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Wed, 11 May 2011 12:49:51 +0200 Subject: [Scilab-loc] Context for Scilab messages In-Reply-To: <1305109107682-2926701.post@n3.nabble.com> References: <1305109107682-2926701.post@n3.nabble.com> Message-ID: <1305110991.28702.20.camel@korcula.inria.fr> Le mercredi 11 mai 2011 ? 03:18 -0700, Yuri Chornoivan a ?crit : > Hi! > > The messages in the current Scilab localization files are sorted > alphabetically that sometimes lead to puzzles where different part of the > same message are scattered through the big translation file. The comments in > PO file will be the good hint in these cases, but they are regretfully not > shown neither in Rosetta, nor in offline editors due to the extra #-line. > > Example: > > # > # File: macros/Sources/tkscaleblk.sci, line: 49 > msgid "&File" > msgstr "" > # > # File: macros/Sources/tkscaleblk.sci, line: 50 > msgid "&Tools" > msgstr "" > > Should be: > > # File: macros/Sources/tkscaleblk.sci, line: 49 > msgid "&File" > msgstr "" > > # File: macros/Sources/tkscaleblk.sci, line: 50 > msgid "&Tools" > msgstr "" > > The question: Is it worth to change the extraction script accordingly? Can > it be changed? You mean the template (.pot) or localization files (.po) ? I have control on the template but .po are coming from launchpad and I am doing a basic copy. Sylvestre From yurchor at ukr.net Wed May 11 13:12:43 2011 From: yurchor at ukr.net (Yuri Chornoivan) Date: Wed, 11 May 2011 04:12:43 -0700 (PDT) Subject: Context for Scilab messages In-Reply-To: <1305110991.28702.20.camel@korcula.inria.fr> References: <1305109107682-2926701.post@n3.nabble.com> <1305110991.28702.20.camel@korcula.inria.fr> Message-ID: ???????? Wed, 11 May 2011 13:49:55 +0300, sylvestre [via Scilab / Xcos - Mailing Lists Archives] : >> The question: Is it worth to change the extraction script accordingly? >> Can >> it be changed? > You mean the template (.pot) or localization files (.po) ? > I have control on the template but .po are coming from launchpad and I > am doing a basic copy. > > Sylvestre I mean templates. And I was wrong... Some further investigation shows that for some reason Launchpad ignores (and strips away) Scilab comments like this: # # File: macros/Sources/tkscaleblk.sci, line: 51 But shows the comments like this (Inkscape): #: ../share/filters/filters.svg.h:133 Lokalize and Virtaal show the comments from the raw Scilab template flawlessly, but there are no comments in the PO-files exported from LP. Really strange... Rosetta bug? Thanks in advance for the hints. Yuri -- View this message in context: http://mailinglists.scilab.org/Context-for-Scilab-messages-tp2926701p2926851.html Sent from the Scilab localization - Mailing Lists Archives mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvestre.ledru at scilab.org Wed May 11 13:27:46 2011 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Wed, 11 May 2011 13:27:46 +0200 Subject: [Scilab-loc] Re: Context for Scilab messages In-Reply-To: References: <1305109107682-2926701.post@n3.nabble.com> <1305110991.28702.20.camel@korcula.inria.fr> Message-ID: <1305113266.28702.22.camel@korcula.inria.fr> Le mercredi 11 mai 2011 ? 04:12 -0700, Yuri Chornoivan a ?crit : > ???????? Wed, 11 May 2011 13:49:55 +0300, sylvestre [via Scilab / Xcos > - > Mailing Lists Archives] <[hidden email]>: > > >> The question: Is it worth to change the extraction script > accordingly? > >> Can > >> it be changed? > > You mean the template (.pot) or localization files (.po) ? > > I have control on the template but .po are coming from launchpad and > I > > am doing a basic copy. > > > > Sylvestre > > I mean templates. > > And I was wrong... Some further investigation shows that for some > reason > Launchpad ignores (and strips away) Scilab comments like this: > > # > # File: macros/Sources/tkscaleblk.sci, line: 51 > > But shows the comments like this (Inkscape): > > #: ../share/filters/filters.svg.h:133 > > Lokalize and Virtaal show the comments from the raw Scilab template > flawlessly, but there are no comments in the PO-files exported from > LP. > > Really strange... Rosetta bug? Rosetta maintainers are reactive and already fixed some bugs for us. You should report a bug: https://launchpad.net/launchpad S From yurchor at ukr.net Wed May 11 13:55:08 2011 From: yurchor at ukr.net (Yuri Chornoivan) Date: Wed, 11 May 2011 04:55:08 -0700 (PDT) Subject: Context for Scilab messages In-Reply-To: <1305113266.28702.22.camel@korcula.inria.fr> References: <1305109107682-2926701.post@n3.nabble.com> <1305110991.28702.20.camel@korcula.inria.fr> <1305113266.28702.22.camel@korcula.inria.fr> Message-ID: ???????? Wed, 11 May 2011 14:27:49 +0300, sylvestre [via Scilab / Xcos - Mailing Lists Archives] : > Rosetta maintainers are reactive and already fixed some bugs for us. You > should report a bug: > https://launchpad.net/launchpad > > S Done. https://bugs.launchpad.net/launchpad/+bug/781094 -- View this message in context: http://mailinglists.scilab.org/Context-for-Scilab-messages-tp2926701p2926971.html Sent from the Scilab localization - Mailing Lists Archives mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvestre.ledru at scilab.org Fri May 13 11:38:24 2011 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Fri, 13 May 2011 11:38:24 +0200 Subject: Opinions on the localization of the help pages Message-ID: <1305279504.14358.25.camel@korcula.inria.fr> Hello guys, While Scilab itself is pretty well translated, it is not really the case of it documentation. In English, the reference, we have 2393 xml files (usually, more or less a page). It is docbook files. We have translations in French, portugues do brazil & japanese. Clement suggested to use xml2po & po2xml to simplify the work: http://bugzilla.scilab.org/show_bug.cgi?id=9481 and pluggin it with launchpad. What is your opinions on this ? Thanks S From yurchor at ukr.net Sat May 14 19:02:41 2011 From: yurchor at ukr.net (Yuri Chornoivan) Date: Sat, 14 May 2011 10:02:41 -0700 (PDT) Subject: Opinions on the localization of the help pages In-Reply-To: <1305279504.14358.25.camel@korcula.inria.fr> References: <1305279504.14358.25.camel@korcula.inria.fr> Message-ID: ???????? Sat, 14 May 2011 17:08:45 +0300, sylvestre [via Scilab / Xcos - Mailing Lists Archives] : > > > Hello guys, > > While Scilab itself is pretty well translated, it is not really the case > of it documentation. > In English, the reference, we have 2393 xml files (usually, more or less > a page). It is docbook files. > We have translations in French, portugues do brazil & japanese. > > Clement suggested to use xml2po & po2xml to simplify the work: > http://bugzilla.scilab.org/show_bug.cgi?id=9481 > and pluggin it with launchpad. > > What is your opinions on this ? Hi! It seems that it will be problematic to make the full translation during the next release cycle. On the other hand po2xml generates docbook only for 100% translated PO that is 100% XML-compliant. It is good for consistency, but Rosetta do not check the XML (it is well known that Ubuntu docs are broken for many languages because the translators ignore the guidelines or use the wrong guidelines). In KDE we use pology+Lokalize to debug POs with XML code, but it can be the overkill for Scilab. Thus, The following questions have to be answered: 1. The improper POs can be excluded from docbook generation, but how to send the message with the errors to the translators? 2. To generate docbooks from the partial translation we can modify po2xml (patches can be found in kde-i18n-doc, I can give the links if needed) or use po4a (it seems to me that in this case it will be also better to use po4a for generate POTs generation). So what the proper level of the translation to include it into the release? 3. If there is no translation English docbook should be shown. Is this feasible? If these issues can be solved, I think there are no other obstacles to make the docs translatable. Thanks in advance for the answers. Best regards, Yuri -- View this message in context: http://mailinglists.scilab.org/Opinions-on-the-localization-of-the-help-pages-tp2938392p2940594.html Sent from the Scilab localization - Mailing Lists Archives mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From k.nielsen81 at gmail.com Sat May 14 23:13:45 2011 From: k.nielsen81 at gmail.com (Kenneth Nielsen) Date: Sat, 14 May 2011 23:13:45 +0200 Subject: [Scilab-loc] Re: Opinions on the localization of the help pages In-Reply-To: References: <1305279504.14358.25.camel@korcula.inria.fr> Message-ID: Hey > Hi! > > It seems that it will be problematic to make the full translation during > the next release cycle. > > On the other hand po2xml generates docbook only for 100% translated PO > that is 100% XML-compliant. > It is good for consistency, but Rosetta do not check the XML (it is well > known that Ubuntu docs are broken for many languages because the > translators ignore the guidelines or use the wrong guidelines). In KDE we > use pology+Lokalize to debug POs with XML code, but it can be the overkill > for Scilab. Alternatively you can also use gtxml (GetTextXML) from the pyg3t package (of which I'm a co-author, this is really just shameless adverticement ;)). gtxml is written by a fellow Danish translator Ask H. Larsen. It is a commandline tool that generates helpful error messages, so it can be used e.g. for checking the xml of all the localised files and sending out a combined email with errors for all of them. > Thus, The following questions have to be answered: > > 1. The improper POs can be excluded from docbook generation, but how to > send the message with the errors to the translators? gtxml could produce the errors, the communication is a bit more tricky. It might also be hooked in a build script to exclude broken files at build time, but I guess maybe the proper way to fix the problem, is to do the check as a commit hook, so the bad files never make it in the source tree. Regards Kenneth > 2. To generate docbooks from the partial translation we can modify po2xml > (patches can be found in kde-i18n-doc, I can give the links if needed) or > use po4a (it seems to me that in this case it will be also better to use > po4a for generate POTs generation). So what the proper level of the > translation to include it into the release? > > 3. If there is no translation English docbook should be shown. Is this > feasible? > > If these issues can be solved, I think there are no other obstacles to > make the docs translatable. > > Thanks in advance for the answers. > > Best regards, > Yuri > > ________________________________ > View this message in context: Re: Opinions on the localization of the help > pages > Sent from the Scilab localization - Mailing Lists Archives mailing list > archive at Nabble.com. > From k.nielsen81 at gmail.com Sat May 14 23:16:03 2011 From: k.nielsen81 at gmail.com (Kenneth Nielsen) Date: Sat, 14 May 2011 23:16:03 +0200 Subject: [Scilab-loc] Re: Opinions on the localization of the help pages In-Reply-To: References: <1305279504.14358.25.camel@korcula.inria.fr> Message-ID: 2011/5/14 Kenneth Nielsen : > Hey > >> Hi! >> >> It seems that it will be problematic to make the full translation during >> the next release cycle. >> >> On the other hand po2xml generates docbook only for 100% translated PO >> that is 100% XML-compliant. >> It is good for consistency, but Rosetta do not check the XML (it is well >> known that Ubuntu docs are broken for many languages because the >> translators ignore the guidelines or use the wrong guidelines). In KDE we >> use pology+Lokalize to debug POs with XML code, but it can be the overkill >> for Scilab. > > Alternatively you can also use gtxml (GetTextXML) from the pyg3t > package (of which I'm a co-author, this is really just shameless > adverticement ;)). gtxml is written by a fellow Danish translator Ask > H. Larsen. It is a commandline tool that generates helpful error > messages, so it can be used e.g. for checking the xml of all the > localised files and sending out a combined email with errors for all > of them. > >> Thus, The following questions have to be answered: >> >> 1. The improper POs can be excluded from docbook generation, but how to >> send the message with the errors to the translators? > > gtxml could produce the errors, the communication is a bit more > tricky. It might also be hooked in a build script to exclude broken > files at build time, but I guess maybe the proper way to fix the Uhh I forgot to say that this has never been done though. It is a relatively new tool. > problem, is to do the check as a commit hook, so the bad files never > make it in the source tree. > > Regards Kenneth > >> 2. To generate docbooks from the partial translation we can modify po2xml >> (patches can be found in kde-i18n-doc, I can give the links if needed) or >> use po4a (it seems to me that in this case it will be also better to use >> po4a for generate POTs generation). So what the proper level of the >> translation to include it into the release? >> >> 3. If there is no translation English docbook should be shown. Is this >> feasible? >> >> If these issues can be solved, I think there are no other obstacles to >> make the docs translatable. >> >> Thanks in advance for the answers. >> >> Best regards, >> Yuri >> >> ________________________________ >> View this message in context: Re: Opinions on the localization of the help >> pages >> Sent from the Scilab localization - Mailing Lists Archives mailing list >> archive at Nabble.com. >> > From sylvestre.ledru at scilab.org Wed May 18 17:42:18 2011 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Wed, 18 May 2011 17:42:18 +0200 Subject: [Scilab-loc] Re: Opinions on the localization of the help pages In-Reply-To: References: <1305279504.14358.25.camel@korcula.inria.fr> Message-ID: <1305733338.2052.12.camel@korcula.inria.fr> Le samedi 14 mai 2011 ? 10:02 -0700, Yuri Chornoivan a ?crit : > ???????? Sat, 14 May 2011 17:08:45 +0300, sylvestre [via Scilab / Xcos > - > Mailing Lists Archives] <[hidden email]>: > > > > > > > Hello guys, > > > > While Scilab itself is pretty well translated, it is not really the > case > > of it documentation. > > In English, the reference, we have 2393 xml files (usually, more or > less > > a page). It is docbook files. > > We have translations in French, portugues do brazil & japanese. > > > > Clement suggested to use xml2po & po2xml to simplify the work: > > http://bugzilla.scilab.org/show_bug.cgi?id=9481 > > and pluggin it with launchpad. > > > > What is your opinions on this ? > > Hi! > > It seems that it will be problematic to make the full translation > during > the next release cycle. It is not that I am expecting. I am more thinking about good tool to manage that. > Thus, The following questions have to be answered: > > 1. The improper POs can be excluded from docbook generation, but how > to > send the message with the errors to the translators? It is already a problem with the current localization process. > 2. To generate docbooks from the partial translation we can modify > po2xml > (patches can be found in kde-i18n-doc, I can give the links if needed) > or > use po4a (it seems to me that in this case it will be also better to > use > po4a for generate POTs generation). So what the proper level of the > translation to include it into the release? At least a third of the documentation translated would be nice. What is your opinion on this ? > 3. If there is no translation English docbook should be shown. Is > this > feasible? The english original doc will be available. For example: #: mlist.xml:50(para) msgid "The semantic of the extraction and insertion syntax should be given by an overloading functions." msgstr "" Sylvestre From sylvestre.ledru at scilab.org Wed May 18 17:43:33 2011 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Wed, 18 May 2011 17:43:33 +0200 Subject: [Scilab-loc] Re: Opinions on the localization of the help pages In-Reply-To: References: <1305279504.14358.25.camel@korcula.inria.fr> Message-ID: <1305733413.2052.13.camel@korcula.inria.fr> Le samedi 14 mai 2011 ? 23:13 +0200, Kenneth Nielsen a ?crit : > Hey > > > Hi! > > > > It seems that it will be problematic to make the full translation during > > the next release cycle. > > > > On the other hand po2xml generates docbook only for 100% translated PO > > that is 100% XML-compliant. > > It is good for consistency, but Rosetta do not check the XML (it is well > > known that Ubuntu docs are broken for many languages because the > > translators ignore the guidelines or use the wrong guidelines). In KDE we > > use pology+Lokalize to debug POs with XML code, but it can be the overkill > > for Scilab. > > Alternatively you can also use gtxml (GetTextXML) from the pyg3t > package (of which I'm a co-author, this is really just shameless > adverticement ;)). gtxml is written by a fellow Danish translator Ask > H. Larsen. It is a commandline tool that generates helpful error > messages, so it can be used e.g. for checking the xml of all the > localised files and sending out a combined email with errors for all > of them. Do you have some documents and use cases of it ? thanks, S From yurchor at ukr.net Wed May 18 17:55:43 2011 From: yurchor at ukr.net (Yuri Chornoivan) Date: Wed, 18 May 2011 08:55:43 -0700 (PDT) Subject: Opinions on the localization of the help pages In-Reply-To: <1305733338.2052.12.camel@korcula.inria.fr> References: <1305279504.14358.25.camel@korcula.inria.fr> <1305733338.2052.12.camel@korcula.inria.fr> Message-ID: ???????? Wed, 18 May 2011 18:42:29 +0300, sylvestre [via Scilab / Xcos - Mailing Lists Archives] : >> 2. To generate docbooks from the partial translation we can modify >> po2xml >> (patches can be found in kde-i18n-doc, I can give the links if needed) >> or >> use po4a (it seems to me that in this case it will be also better to >> use >> po4a for POTs generation). So what is the proper level of the >> translation to include it into the release? > At least a third of the documentation translated would be nice. What is > your opinion on this ? That is good for me. :) -- View this message in context: http://mailinglists.scilab.org/Opinions-on-the-localization-of-the-help-pages-tp2938392p2957563.html Sent from the Scilab localization - Mailing Lists Archives mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvestre.ledru at scilab.org Thu May 19 10:48:07 2011 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Thu, 19 May 2011 10:48:07 +0200 Subject: Question to our localization specialist Message-ID: <1305794887.6713.8.camel@korcula.inria.fr> Hello guys, Since some of you are localization specialist, I would like to have some advices. In the latest release of Scilab, a critical issue in the Polish and Japanese localizations has been found. This causes a bad exception and Scinotes to be unusable: http://bugzilla.scilab.org/show_bug.cgi?id=9475 I was wondering if you know any tool which might check the quality of the translation regarding the programming language. For example, in Scilab, I will write: myString = "I don''t known" Some translators are not very familiar with specificities of languages. They might think the double quote might just be a typo and remove it from the translated string. This is bad since it breaks the execution since the string is badly formatted. Do you know a tool which might here ? (it is hard for us to test Scilab in all the languages). Thanks, Sylvestre From rokach at tu.kielce.pl Thu May 19 12:15:19 2011 From: rokach at tu.kielce.pl (Ihor Rokach) Date: Thu, 19 May 2011 12:15:19 +0200 Subject: [Scilab-loc] Question to our localization specialist In-Reply-To: <1305794887.6713.8.camel@korcula.inria.fr> References: <1305794887.6713.8.camel@korcula.inria.fr> Message-ID: <0F39FDD48D5E42BF915C30C8701ABEDA@c213rokach> I think that in general such mistakes are unavoidable. The problem is we (translators) sometimes have no chance to check even the basic features of a new Scilab release in advance (there is no such things as release candidate in this project). Scilab 5.3.2 was released without external testing, so the result is as it is. Additionally, in Scilab project there are no "service packs" or patches, to fix the simplest bugs of the current stable release. These two tools can be used for fixing all types of bugs in Scilab, not only those connected with localization. With best wishes, == I.Rokach > -----Original Message----- > From: Sylvestre Ledru [mailto:sylvestre.ledru at scilab.org] > Sent: Thursday, May 19, 2011 10:48 AM > To: localization at lists.scilab.org > Subject: [Scilab-loc] Question to our localization specialist > > Hello guys, > > Since some of you are localization specialist, I would like to have some > advices. > > In the latest release of Scilab, a critical issue in the Polish and > Japanese localizations has been found. This causes a bad exception and > Scinotes to be unusable: > http://bugzilla.scilab.org/show_bug.cgi?id=9475 > > I was wondering if you know any tool which might check the quality of > the translation regarding the programming language. > > For example, in Scilab, I will write: > myString = "I don''t known" > > Some translators are not very familiar with specificities of languages. > They might think the double quote might just be a typo and remove it > from the translated string. > This is bad since it breaks the execution since the string is badly > formatted. > > Do you know a tool which might here ? (it is hard for us to test Scilab > in all the languages). > > Thanks, > Sylvestre From sylvestre.ledru at scilab.org Thu May 19 12:47:55 2011 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Thu, 19 May 2011 12:47:55 +0200 Subject: [Scilab-loc] Question to our localization specialist In-Reply-To: <0F39FDD48D5E42BF915C30C8701ABEDA@c213rokach> References: <1305794887.6713.8.camel@korcula.inria.fr> <0F39FDD48D5E42BF915C30C8701ABEDA@c213rokach> Message-ID: <1305802075.3802.12.camel@korcula.inria.fr> Well, Scilab is providing a daily basis nightly builds [1] which are exactly the same as a normal release except the version name. About testing, we sent a private email to the people who got a git access to make sure they check their works. If we did it privately (ie not on the dev mailing list), it is because the files are named exactly like the final release. We cannot take the risk of having two Scilab tarballs with the exact same name. If you want to be included on that list, please let me know. Anyway, yes, we might make a beta even of minor releases for such things... We are doing it for all major releases [2]. Sylvestre [1] http://www.scilab.org/fr/communities/developer_zone/scilab_versions/development_version/nightly_builds/ [2] http://cgit.scilab.org/scilab/refs/tags Le jeudi 19 mai 2011 ? 12:15 +0200, Ihor Rokach a ?crit : > I think that in general such mistakes are unavoidable. The problem is we > (translators) sometimes have no chance to check even the basic features of a > new Scilab release in advance (there is no such things as release candidate > in this project). Scilab 5.3.2 was released without external testing, so the > result is as it is. > > Additionally, in Scilab project there are no "service packs" or patches, to > fix the simplest bugs of the current stable release. > > These two tools can be used for fixing all types of bugs in Scilab, not only > those connected with localization. > > With best wishes, > == > I.Rokach > > > -----Original Message----- > > From: Sylvestre Ledru [mailto:sylvestre.ledru at scilab.org] > > Sent: Thursday, May 19, 2011 10:48 AM > > To: localization at lists.scilab.org > > Subject: [Scilab-loc] Question to our localization specialist > > > > Hello guys, > > > > Since some of you are localization specialist, I would like to have some > > advices. > > > > In the latest release of Scilab, a critical issue in the Polish and > > Japanese localizations has been found. This causes a bad exception and > > Scinotes to be unusable: > > http://bugzilla.scilab.org/show_bug.cgi?id=9475 > > > > I was wondering if you know any tool which might check the quality of > > the translation regarding the programming language. > > > > For example, in Scilab, I will write: > > myString = "I don''t known" > > > > Some translators are not very familiar with specificities of languages. > > They might think the double quote might just be a typo and remove it > > from the translated string. > > This is bad since it breaks the execution since the string is badly > > formatted. > > > > Do you know a tool which might here ? (it is hard for us to test Scilab > > in all the languages). > > > > Thanks, > > Sylvestre > From yurchor at ukr.net Thu May 19 13:29:15 2011 From: yurchor at ukr.net (Yuri Chornoivan) Date: Thu, 19 May 2011 04:29:15 -0700 (PDT) Subject: Question to our localization specialist In-Reply-To: <1305794887.6713.8.camel@korcula.inria.fr> References: <1305794887.6713.8.camel@korcula.inria.fr> Message-ID: ???????? Thu, 19 May 2011 12:18:45 +0300, sylvestre [via Scilab / Xcos - Mailing Lists Archives] : > > > Hello guys, > > Since some of you are localization specialist, I would like to have some > advices. > > In the latest release of Scilab, a critical issue in the Polish and > Japanese localizations has been found. This causes a bad exception and > Scinotes to be unusable: > http://bugzilla.scilab.org/show_bug.cgi?id=9475 > > I was wondering if you know any tool which might check the quality of > the translation regarding the programming language. > > For example, in Scilab, I will write: > myString = "I don''t known" > > Some translators are not very familiar with specificities of languages. > They might think the double quote might just be a typo and remove it > from the translated string. > This is bad since it breaks the execution since the string is badly > formatted. > > Do you know a tool which might here ? (it is hard for us to test Scilab > in all the languages). > > Thanks, > Sylvestre Hi! I am not an expert, but there are two tools that are known to me that can do the job. 1. KDE Pology Homepage: http://techbase.kde.org/Localization/Tools/Pology It is easy to write a sieve that automatically corrects the critical mistakes then just run ./posieve.py check-rules --skip-obsolete /path/to/modules/ More on this can be found in Pology documentation: svn co svn co svn://anonsvn.kde.org/home/kde/trunk/l10n-support/pology Rules for the KDE teams can be found in /home/kde/trunk/l10n-support/. 2. Translate Toolkit pofilter Homepage: http://translate.sourceforge.net/wiki/toolkit/pofilter The files that will fail the check for Scilab custom rules can be excluded from package. ------------------------------------------------------------------------- In general, KDE English Breakfast Network ( http://www.englishbreakfastnetwork.org/sanitizer/index.php?component=kde-4.x ) recommends not to use "don't", "can't", "you're", and other forms with apostrophe and prefer "do not", "cannot", "you are". KDE QA Team always corrects such mistakes in interface before the release. Hope this helps. Thanks for your work, Yuri -- View this message in context: http://mailinglists.scilab.org/Question-to-our-localization-specialist-tp2960545p2960930.html Sent from the Scilab localization - Mailing Lists Archives mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From k.nielsen81 at gmail.com Thu May 19 13:33:19 2011 From: k.nielsen81 at gmail.com (Kenneth Nielsen) Date: Thu, 19 May 2011 13:33:19 +0200 Subject: [Scilab-loc] Question to our localization specialist In-Reply-To: <1305794887.6713.8.camel@korcula.inria.fr> References: <1305794887.6713.8.camel@korcula.inria.fr> Message-ID: 2011/5/19 Sylvestre Ledru : > Hello guys, Hallo Sylvester > Since some of you are localization specialist, I would like to have some > advices. > > In the latest release of Scilab, a critical issue in the Polish and > Japanese localizations has been found. This causes a bad exception and > Scinotes to be unusable: > http://bugzilla.scilab.org/show_bug.cgi?id=9475 > > I was wondering if you know any tool which might check the quality of > the translation regarding the programming language. > > For example, in Scilab, I will write: > myString = "I don''t known" I'm not sure if there are any tools that knows the language and can check it. But if you can define a grep like rule for it, you could check it with gtgrep (which is another tool from pyg3t). E.g. if the problem is that when there is a double '' in the msgid then there should also be one in the msgstr. Then you could grep for that with the following command: gtgrep -i "''" -S -s "''" file.po This will look for any message where the msgid has a '' and the msgstr has not. So if the command produces an output then you are in trouble. You could then make a checker script that consist of as many as these check as you like for each language file. In the other thread you were asking about documentation and use cases. I'm afraid that at this point there is no other documentation than the --help messages in the commands. In any case, the tools that Yuri mentions seems to be able to something similar and with a similar amount of work and they seem somewhat more established, so that is probably the way you want to go. Regards Kenneth > Some translators are not very familiar with specificities of languages. > They might think the double quote might just be a typo and remove it > from the translated string. > This is bad since it breaks the execution since the string is badly > formatted. > > Do you know a tool which might here ? (it is hard for us to test Scilab > in all the languages). > > Thanks, > Sylvestre > > From k.nielsen81 at gmail.com Thu May 19 13:39:10 2011 From: k.nielsen81 at gmail.com (Kenneth Nielsen) Date: Thu, 19 May 2011 13:39:10 +0200 Subject: [Scilab-loc] Re: Opinions on the localization of the help pages In-Reply-To: <1305733413.2052.13.camel@korcula.inria.fr> References: <1305279504.14358.25.camel@korcula.inria.fr> <1305733413.2052.13.camel@korcula.inria.fr> Message-ID: 2011/5/18 Sylvestre Ledru : > Le samedi 14 mai 2011 ? 23:13 +0200, Kenneth Nielsen a ?crit : >> Hey >> >> > Hi! >> > >> > It seems that it will be problematic to make the full translation during >> > the next release cycle. >> > >> > On the other hand po2xml generates docbook only for 100% translated PO >> > that is 100% XML-compliant. >> > It is good for consistency, but Rosetta do not check the XML (it is well >> > known that Ubuntu docs are broken for many languages because the >> > translators ignore the guidelines or use the wrong guidelines). In KDE we >> > use pology+Lokalize to debug POs with XML code, but it can be the overkill >> > for Scilab. >> >> Alternatively you can also use gtxml (GetTextXML) from the pyg3t >> package (of which I'm a co-author, this is really just shameless >> adverticement ;)). gtxml is written by a fellow Danish translator Ask >> H. Larsen. It is a commandline tool that generates helpful error >> messages, so it can be used e.g. for checking the xml of all the >> localised files and sending out a combined email with errors for all >> of them. > Do you have some documents and use cases of it ? Unfortunately not. The only documentation at the time is what is in the --help function: Usage: gtxml [OPTION]... [FILE]... Parse the contents of each po-FILE, writing warnings for entries suspected of containing ill-formed xml. A translated entry is considered ill-formed if its msgid is well-formed xml while at least one of its msgstrs is not. If no FILE is given, or if FILE is -, read from stdin. Options: --version show program's version number and exit -h, --help show this help message and exit -s, --summary write only whether each FILE passes or fails, and the number of valid and invalid strings for each file. -f, --fuzzy print warnings for fuzzy entries aside from just translated entries. As for use cases I can provide you with some if you like, but as you can see from the above it is pretty simple. As I said earlier, pyg3t is still a relatively young project, so it would be probably be ok to use for generating warnings that could be sent to an email list, but I would probably be a little hesitant of using it for build time checks at this point. At least you should know, that if you do, you will be the first ones. Regards Kenneth From rokach at tu.kielce.pl Thu May 19 14:00:11 2011 From: rokach at tu.kielce.pl (Ihor Rokach) Date: Thu, 19 May 2011 14:00:11 +0200 Subject: [Scilab-loc] Question to our localization specialist In-Reply-To: <1305802075.3802.12.camel@korcula.inria.fr> References: <1305794887.6713.8.camel@korcula.inria.fr> <0F39FDD48D5E42BF915C30C8701ABEDA@c213rokach> <1305802075.3802.12.camel@korcula.inria.fr> Message-ID: <3834CD5BEABC45CF90B8477A6B60102F@c213rokach> Night builds are not patches anyway. Imagine downloading and installation full M$ Windows just to correct a single bad character in one string. In my university Scilab is installed on 20+ computers in the student lab. After that we have installed several toolboxes via Atoms. So, to correct a single line bug using night build somebody needs to reinstall everything. Additionally, nobody knows when each bug (especially connected with localization) is fixed in a night build. With best wishes, == I.Rokach > -----Original Message----- > From: Sylvestre Ledru [mailto:sylvestre.ledru at scilab.org] > Sent: Thursday, May 19, 2011 12:48 PM > To: localization at lists.scilab.org > Subject: RE: [Scilab-loc] Question to our localization specialist > > Well, Scilab is providing a daily basis nightly builds [1] which are > exactly the same as a normal release except the version name. > > About testing, we sent a private email to the people who got a git > access to make sure they check their works. If we did it privately (ie > not on the dev mailing list), it is because the files are named exactly > like the final release. We cannot take the risk of having two Scilab > tarballs with the exact same name. > If you want to be included on that list, please let me know. > > Anyway, yes, we might make a beta even of minor releases for such > things... We are doing it for all major releases [2]. > > Sylvestre > > [1] > http://www.scilab.org/fr/communities/developer_zone/scilab_versions/develo > pment_version/nightly_builds/ > [2] http://cgit.scilab.org/scilab/refs/tags > > > > Le jeudi 19 mai 2011 ? 12:15 +0200, Ihor Rokach a ?crit : > > I think that in general such mistakes are unavoidable. The problem is we > > (translators) sometimes have no chance to check even the basic features > of a > > new Scilab release in advance (there is no such things as release > candidate > > in this project). Scilab 5.3.2 was released without external testing, so > the > > result is as it is. > > > > Additionally, in Scilab project there are no "service packs" or patches, > to > > fix the simplest bugs of the current stable release. > > > > These two tools can be used for fixing all types of bugs in Scilab, not > only > > those connected with localization. > > > > With best wishes, > > == > > I.Rokach > > > > > -----Original Message----- > > > From: Sylvestre Ledru [mailto:sylvestre.ledru at scilab.org] > > > Sent: Thursday, May 19, 2011 10:48 AM > > > To: localization at lists.scilab.org > > > Subject: [Scilab-loc] Question to our localization specialist > > > > > > Hello guys, > > > > > > Since some of you are localization specialist, I would like to have > some > > > advices. > > > > > > In the latest release of Scilab, a critical issue in the Polish and > > > Japanese localizations has been found. This causes a bad exception and > > > Scinotes to be unusable: > > > http://bugzilla.scilab.org/show_bug.cgi?id=9475 > > > > > > I was wondering if you know any tool which might check the quality of > > > the translation regarding the programming language. > > > > > > For example, in Scilab, I will write: > > > myString = "I don''t known" > > > > > > Some translators are not very familiar with specificities of > languages. > > > They might think the double quote might just be a typo and remove it > > > from the translated string. > > > This is bad since it breaks the execution since the string is badly > > > formatted. > > > > > > Do you know a tool which might here ? (it is hard for us to test > Scilab > > > in all the languages). > > > > > > Thanks, > > > Sylvestre > > From sylvestre.ledru at scilab.org Thu May 19 14:17:08 2011 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Thu, 19 May 2011 14:17:08 +0200 Subject: [Scilab-loc] Question to our localization specialists In-Reply-To: <3834CD5BEABC45CF90B8477A6B60102F@c213rokach> References: <1305794887.6713.8.camel@korcula.inria.fr> <0F39FDD48D5E42BF915C30C8701ABEDA@c213rokach> <1305802075.3802.12.camel@korcula.inria.fr> <3834CD5BEABC45CF90B8477A6B60102F@c213rokach> Message-ID: <1305807428.3802.16.camel@korcula.inria.fr> Le jeudi 19 mai 2011 ? 14:00 +0200, Ihor Rokach a ?crit : > Night builds are not patches anyway. Imagine downloading and installation > full M$ Windows just to correct a single bad character in one string. It is why we started the "Binary patching" project in the context of the GSoC: http://www.scilab.org/projects/development/google > In my university Scilab is installed on 20+ computers in the student lab. > After that we have installed several toolboxes via Atoms. So, to correct a > single line bug using night build somebody needs to reinstall everything. > > Additionally, nobody knows when each bug (especially connected with > localization) is fixed in a night build. I disagree. You will find all the information in the bug report (I agree that you have to know that there is a bug report). Sylvestre From rodolforg at gmail.com Fri May 20 04:24:40 2011 From: rodolforg at gmail.com (Rodolfo) Date: Thu, 19 May 2011 23:24:40 -0300 Subject: [Scilab-loc] Re: Question to our localization specialist In-Reply-To: References: <1305794887.6713.8.camel@korcula.inria.fr> Message-ID: Other tests can be done by using $ msgfmt -cvo /dev/null file.po 2011/5/19 Yuri Chornoivan : > ???????? Thu, 19 May 2011 12:18:45 +0300, sylvestre [via Scilab / Xcos - > Mailing Lists Archives] <[hidden email]>: > >> >> >> Hello guys, >> >> Since some of you are localization specialist, I would like to have some >> advices. >> >> In the latest release of Scilab, a critical issue in the Polish and >> Japanese localizations has been found. This causes a bad exception and >> Scinotes to be unusable: >> http://bugzilla.scilab.org/show_bug.cgi?id=9475 >> >> I was wondering if you know any tool which might check the quality of >> the translation regarding the programming language. >> >> For example, in Scilab, I will write: >> myString = "I don''t known" >> >> Some translators are not very familiar with specificities of languages. >> They might think the double quote might just be a typo and remove it >> from the translated string. >> This is bad since it breaks the execution since the string is badly >> formatted. >> >> Do you know a tool which might here ? (it is hard for us to test Scilab >> in all the languages). >> >> Thanks, >> Sylvestre > Hi! > > I am not an expert, but there are two tools that are known to me that can > do the job. > > 1. KDE Pology > Homepage: http://techbase.kde.org/Localization/Tools/Pology > > It is easy to write a sieve that automatically corrects the critical > mistakes then just run > > ./posieve.py check-rules --skip-obsolete /path/to/modules/ > > More on this can be found in Pology documentation: > > svn co svn co svn://anonsvn.kde.org/home/kde/trunk/l10n-support/pology > > Rules for the KDE teams can be found in /home/kde/trunk/l10n-support/. > > 2. Translate Toolkit pofilter > Homepage: http://translate.sourceforge.net/wiki/toolkit/pofilter > > The files that will fail the check for Scilab custom rules can be excluded > ?from package. > > ------------------------------------------------------------------------- > > In general, KDE English Breakfast Network ( > http://www.englishbreakfastnetwork.org/sanitizer/index.php?component=kde-4.x > ) recommends not to use "don't", "can't", "you're", and other forms with > apostrophe and prefer "do not", "cannot", "you are". KDE QA Team always > corrects such mistakes in interface before the release. > > Hope this helps. > > Thanks for your work, > Yuri > > ________________________________ > View this message in context: Re: Question to our localization specialist > Sent from the Scilab localization - Mailing Lists Archives mailing list > archive at Nabble.com. > From yurchor at ukr.net Fri May 20 08:47:49 2011 From: yurchor at ukr.net (Yuri Chornoivan) Date: Thu, 19 May 2011 23:47:49 -0700 (PDT) Subject: Question to our localization specialist In-Reply-To: References: <1305794887.6713.8.camel@korcula.inria.fr> Message-ID: <1305874069810-2964573.post@n3.nabble.com> Almost forgot about this tool from LyX: http://www.lyx.org/trac/browser/lyx-devel/trunk/po/pocheck.pl It is lightweight and can be easily tweaked to improve QA (although some false positive warnings can occur). -- View this message in context: http://mailinglists.scilab.org/Question-to-our-localization-specialist-tp2960545p2964573.html Sent from the Scilab localization - Mailing Lists Archives mailing list archive at Nabble.com. From sylvestre.ledru at scilab.org Fri May 20 09:08:42 2011 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Fri, 20 May 2011 09:08:42 +0200 Subject: [Scilab-loc] Re: Question to our localization specialist In-Reply-To: <1305874069810-2964573.post@n3.nabble.com> References: <1305794887.6713.8.camel@korcula.inria.fr> <1305874069810-2964573.post@n3.nabble.com> Message-ID: <1305875322.9922.4.camel@losinj.inria.fr> Thanks to all of you for all these tools! I will have a look. Sylvestre Le jeudi 19 mai 2011 ? 23:47 -0700, Yuri Chornoivan a ?crit : > Almost forgot about this tool from LyX: > > http://www.lyx.org/trac/browser/lyx-devel/trunk/po/pocheck.pl > > It is lightweight and can be easily tweaked to improve QA (although some > false positive warnings can occur). > > -- > View this message in context: http://mailinglists.scilab.org/Question-to-our-localization-specialist-tp2960545p2964573.html > Sent from the Scilab localization - Mailing Lists Archives mailing list archive at Nabble.com. From sylvestre.ledru at scilab.org Tue May 24 18:28:19 2011 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Tue, 24 May 2011 18:28:19 +0200 Subject: [Scilab-loc] Re: Question to our localization specialist In-Reply-To: <1305874069810-2964573.post@n3.nabble.com> References: <1305794887.6713.8.camel@korcula.inria.fr> <1305874069810-2964573.post@n3.nabble.com> Message-ID: <1306254499.23232.17.camel@losinj.inria.fr> Hello guys, So, here is a feedback on what I am trying to implement. Following an idea of Vincent C, I split the string coming from Scilab codes with the one coming from C, C++ and Java. This because of the too many differences between the two worlds. The modification is available here: http://codereview.scilab.org/#change,4101 The result has not been accepted yet into the git repository (because we are considering to do an early release for the polish and japanese bugs). Strings have been properly dispatched between the two modules. After that, I used the script proposed by Yuri and extended to detect and fix Scilab localization errors. This script is available here: http://codereview.scilab.org/#change,4113 Thanks Yuri. It helped a lot. Finally, I ran this script and updated the localization files: http://codereview.scilab.org/#change,4112 Now, once new modules are accepted into launchpad, we should have way less such errors. I will also use the tool "POFileConsistency" from gettext-lint which checks over all the localization files the inconsistencies over translations. Thanks for your feedbacks and suggestions, it helped a lot, Sylvestre Le jeudi 19 mai 2011 ? 23:47 -0700, Yuri Chornoivan a ?crit : > Almost forgot about this tool from LyX: > > http://www.lyx.org/trac/browser/lyx-devel/trunk/po/pocheck.pl > > It is lightweight and can be easily tweaked to improve QA (although some > false positive warnings can occur). > > -- > View this message in context: http://mailinglists.scilab.org/Question-to-our-localization-specialist-tp2960545p2964573.html > Sent from the Scilab localization - Mailing Lists Archives mailing list archive at Nabble.com. From rui.hirokawa at gmail.com Wed May 25 15:47:20 2011 From: rui.hirokawa at gmail.com (Rui Hirokawa) Date: Wed, 25 May 2011 22:47:20 +0900 Subject: [Scilab-loc] Question to our localization specialist In-Reply-To: <1305794887.6713.8.camel@korcula.inria.fr> References: <1305794887.6713.8.camel@korcula.inria.fr> Message-ID: <4DDD0868.1010800@gmail.com> Hello, I found a critical issue in SciNotes of Scilab 5.3.1. I think it is already resolved in Scilab 5.3.2. Bug #9475 is reported for the Polish localized version. It is also an issue in Japanese version ? The consistency check for the format is always difficult problem. For the localization project of PHP (http://php.net/docs.php) which I have been working for, the DocBook XML validator/checker is used. For the detail of project, please look at, https://doc.php.net/php/dochowto/ The up-to-date check for the localized version is also important because the original english version is always updated. For the PHP localization, the changes for the english version is summarized in the web site. https://doc.php.net/php/ja/revcheck.php?p=files&user=hirokawa Rui (2011/05/19 17:48), Sylvestre Ledru wrote: > Hello guys, > > Since some of you are localization specialist, I would like to have some > advices. > > In the latest release of Scilab, a critical issue in the Polish and > Japanese localizations has been found. This causes a bad exception and > Scinotes to be unusable: > http://bugzilla.scilab.org/show_bug.cgi?id=9475 > > I was wondering if you know any tool which might check the quality of > the translation regarding the programming language. > > For example, in Scilab, I will write: > myString = "I don''t known" > > Some translators are not very familiar with specificities of languages. > They might think the double quote might just be a typo and remove it > from the translated string. > This is bad since it breaks the execution since the string is badly > formatted. > > Do you know a tool which might here ? (it is hard for us to test Scilab > in all the languages). > > Thanks, > Sylvestre > > From sylvestre.ledru at scilab.org Wed May 25 16:44:48 2011 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Wed, 25 May 2011 16:44:48 +0200 Subject: [Scilab-loc] Question to our localization specialist In-Reply-To: <4DDD0868.1010800@gmail.com> References: <1305794887.6713.8.camel@korcula.inria.fr> <4DDD0868.1010800@gmail.com> Message-ID: <1306334688.1062.18.camel@korcula.inria.fr> Le mercredi 25 mai 2011 ? 22:47 +0900, Rui Hirokawa a ?crit : > Hello, > > I found a critical issue in SciNotes of Scilab 5.3.1. > I think it is already resolved in Scilab 5.3.2. > Bug #9475 is reported for the Polish localized version. > It is also an issue in Japanese version ? Looks like it. We are thinking about releasing a 5.3.3 version just to fix it... Sylvestre From sylvestre.ledru at scilab.org Tue May 31 14:57:32 2011 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Tue, 31 May 2011 14:57:32 +0200 Subject: Translation template import - tclsci-macros in Scilab trunk In-Reply-To: <20110531124920.24353.25693.launchpad@loganberry.canonical.com> References: <20110531124920.24353.25693.launchpad@loganberry.canonical.com> Message-ID: <1306846652.4606.104.camel@korcula.inria.fr> Hello, Le mardi 31 mai 2011 ? 12:49 +0000, rosetta at launchpad.net a ?crit : > Hello Scilab.team, > > On 2011-05-26 16:20z (4 days 20 hours 28 minutes ago), you uploaded a > translation template for tclsci-macros in Scilab trunk in Launchpad. > > The template has now been imported successfully. Don't worry, your translations have not been lost. Launchpad should import the translated *-macros files pretty soon. Sylvestre