Translation breakage keeps to be a problem for community translator due to the lack of respect of freezes and of the tendency to include upstream translations in the openSUSE tree.
Hanging around in the translation channel, I have just found out that even for 11.1 things didn't change:
- Packagekit translations are still there, while the product is upstream. Again, if it is untranslated, it doesn't really matter. OpenSUSE decided to go with it when not ready, and it really seems you are asking the community to make it ready for SLE with this behaviour.
- KDE 4 backports and fixes added hundreds of strings after freeze, in the desperate attempt to bring KDE 4 at a usable state, when clearly it is not ready yet, and the planning of 11.1 release doesn't match KDE 4.2 release plan.
- YaST fixes, improvements and development added about other 100 strings to translators again. While fixes are welcome, you should really stop changing hundreds of strings when fixing a bug, which is often cosmetic (don't tell me that changing comma positions, or dots or using synonyms is not cosmetic, please).
I know I pointed out this issue many times when I was a translator myself, but I consider it a real problem when working in a community. It is a real form of lack of respect for those who invest their spare time in translation work, to see it partly destroyed by the lack of care of developers, who repeatedly misbehaved on this side.
If a freeze is decided, it _must_ be respected as strictly as possible. And if you need to fix a plasmoid at the last minute, or to change one hundred of strings in yast, it simply means you planned it wrong, and that functionality _should_not_make_it_ in the distribution.
I asked in the past, without seeing any improvement, for a better planning in this field. It is _the_ condition to attract new contributors and to _keep_ them involved. Frustrating people with the current way of doing is not really working, and is demotivating them.
Regards, Alberto
Am Donnerstag 30 Oktober 2008 schrieb Alberto Passalacqua:
Hi Alberto,
- KDE 4 backports and fixes added hundreds of strings after freeze, in
the desperate attempt to bring KDE 4 at a usable state, when clearly it is not ready yet, and the planning of 11.1 release doesn't match KDE 4.2 release plan.
The strings were added after a translator testing the beta asked for the strings to become translatable. Only a very small part of it is KDE 4.2
- YaST fixes, improvements and development added about other 100 strings
to translators again. While fixes are welcome, you should really stop changing hundreds of strings when fixing a bug, which is often cosmetic (don't tell me that changing comma positions, or dots or using synonyms is not cosmetic, please).
I checked briefly the diff of today and I indeed see a lot of SLE development adding strings, but I fail to spot comma position changes at this point.
Having the SLE development in parallel with openSUSE _is_ a problem and it's not just one for translators. Of course you can claim that community translators is the most important aspect of development, but I'm afraid it's just one aspect. E.g. we could branch out yast now and freeze it for openSUSE, but then we would also lack all the fixes done now. So basically we decided to go for more fixes and a possible lack of translations at some points. But as we did with past releases, we'll ship translation updates where it makes sense.
Greetings, Stephan
Hi Stephan,
my point would have wanted to be more general than "translations", but probably I didn't explain it well. I also want to clarify that I decided to opened this thread because some translators were discussing about the frequent string change (I'm not one of them anymore, hopefully!).
However, I am always been for a _hard_freeze_ at a certain point of the development, because I don't believe that running for the last fix is something useful, if the problem is not serious. Of course my definition of "serious" problem does not correspond to the "blocker" of bugzilla, but it is more extended. However this is another topic.
The strings were added after a translator testing the beta asked for the strings to become translatable. Only a very small part of it is KDE 4.2
I think I know who asked for that. ;-) Still, I think it should be refused because that translator gave more work to everyone else in the translation teams without consulting them.
I checked briefly the diff of today and I indeed see a lot of SLE development adding strings, but I fail to spot comma position changes at this point.
Well, I don't think it is a problem in general. You know I have nothing against that. It becomes a problem if it adds work, like in the packagekit case, because upstream the product was not finished. We all agreed during 11.0 development that this practise should have been limited.
Having the SLE development in parallel with openSUSE _is_ a problem and it's not just one for translators. Of course you can claim that community translators is the most important aspect of development, but I'm afraid it's just one aspect.
Well, I didn't write that. I'm just trying to improve how the things work for every part. I think that a better planning would lead to less hurry for everyone, and finally to a better product. That's all.
E.g. we could branch out yast now and freeze it for openSUSE, but then we would also lack all the fixes done now. So basically we decided to go for more fixes and a possible lack of translations at some points. But as we did with past releases, we'll ship translation updates where it makes sense.
I admit 11.1 has a very long freeze period, so it is a sort of exception. However, I tend to think that a branch at a certain point (not the last week of the development) would improve things. Of course this would require a different planning of the development phases.
For example, in the years I spent around openSUSE, I always noticed that changes are done from the middle of the alpha stage to the beginning of the beta stage, while the first alpha's are relatively unchanged. Shifting this back would allow more changes and fixes in the "second part" of alpha stage, and the beginning of beta stage, allowing for a real hard feature freeze at some point in beta phase. I would also stop the continuous changes in core system modules, like YaST. Some modules (printer module is a good example) were changed at each release, without consulting users if not just publishing screenshots and mockups. This resulted in an increased work for everyone without a real need. Some features were added, but they could have been added to the old module in an incremental manner, instead than starting from scratch, with the obvious risk to increase bugs, fixes, translation breakage.
Of course, this is my opinion from outside, but well, I would like the discussion to be done somewhere, maybe on a more appropriate ML, if others are interested.
Regards, Alberto
Am Donnerstag, 30. Oktober 2008 23:36:27 schrieb Alberto Passalacqua:
For example, in the years I spent around openSUSE, I always noticed that changes are done from the middle of the alpha stage to the beginning of the beta stage, while the first alpha's are relatively unchanged. Shifting this back would allow more changes and fixes in the "second part" of alpha stage, and the beginning of beta stage, allowing for a real hard feature freeze at some point in beta phase. I would also stop the continuous changes in core system modules, like YaST. Some modules (printer module is a good example) were changed at each release, without consulting users if not just publishing screenshots and mockups. This resulted in an increased work for everyone without a real need. Some features were added, but they could have been added to the old module in an incremental manner, instead than starting from scratch, with the obvious risk to increase bugs, fixes, translation breakage.
Of course, this is my opinion from outside, but well, I would like the discussion to be done somewhere, maybe on a more appropriate ML, if others are interested.
I think this is an very interesting therad point (I remember a similar ones last release, but they didn't go anywhere). I of course have to admit I'm not familiar with the internal roadmap, but I can relate to (some of) the things Alberto pointed out. I think there's potencial for improvement.
Regards Michael
I think this is an very interesting therad point (I remember a similar ones last release, but they didn't go anywhere).
Yes, I try to re-open this topic at each release, because the situation is always the same. :-)
I of course have to admit I'm not familiar with the internal roadmap,
I don't think a lot of people in the community know the internal roadmap. We know release dates, but we have no idea of what will be changed and what parts are being worked on, if not in general. I think it is probably difficult to keep us up to date on every single detail, but at the same time a sort of "goals for the release", where main changes are summed up would be beneficial (maybe it exists and I don't know of it, though).
Regards, Alberto
Am Donnerstag 30 Oktober 2008 schrieb Alberto Passalacqua:
The strings were added after a translator testing the beta asked for the strings to become translatable. Only a very small part of it is KDE 4.2
I think I know who asked for that. ;-) Still, I think it should be refused because that translator gave more work to everyone else in the translation teams without consulting them.
This is something I don't understand. It would have been english without the bug and if it's english without the work done. So why bother? Is your goal a "100%" string somewhere or an italian desktop?
E.g. we could branch out yast now and freeze it for openSUSE, but then we would also lack all the fixes done now. So basically we decided to go for more fixes and a possible lack of translations at some points. But as we did with past releases, we'll ship translation updates where it makes sense.
I admit 11.1 has a very long freeze period, so it is a sort of exception. However, I tend to think that a branch at a certain point (not the last week of the development) would improve things. Of course this would require a different planning of the development phases.
For example, in the years I spent around openSUSE, I always noticed that changes are done from the middle of the alpha stage to the beginning of the beta stage, while the first alpha's are relatively unchanged. Shifting this back would allow more changes and fixes in the "second part" of alpha stage, and the beginning of beta stage, allowing for a real hard feature freeze at some point in beta phase. I would also stop
Well, alphas see a lot of underlying changes that make it very often even impossible to develop against them. And usually the developers are blocked with other products during the alpha phase. But beta1 is really the point in time where the developers submit new features to the build, adding the strings. Then someone actually tests the beta and we find reasons to add more strings (just read opensuse-factory to spot 'well, just add a checkbox or a popup - it's just beta4').
The problem is, as said earlier, easy to fix if all you care for are translations: just don't change anything. But I'm afraid, for me, it's just one aspect out of many. We're trying constantly (and when I say we I mainly mean Karl and me I'm afraid :) to find ways to make it as easy as possile for the translators. But if you then complain that we make strings translatable that weren't in earlier betas, I fail to understand what you're up to.
I'm open to a discussion on how to improve things, but I'm afraid the things are not as easy as you may think. There are cases where I don't understand why they are still done either, but we will clarify them. PackageKit and yast2-support are two cases that souldn't be in lcn by now IMO (but then again, I was offline for 9 weeks).
Greetings, Stephan
2008/10/31 Stephan Kulow coolo@suse.de
Am Donnerstag 30 Oktober 2008 schrieb Alberto Passalacqua:
The strings were added after a translator testing the beta asked for the strings to become translatable. Only a very small part of it is KDE 4.2
I think I know who asked for that. ;-)
It's me who asked that, did you guess right ;-)
Still, I think it should be refused because that translator gave more work to everyone else in the translation teams without consulting them.
This is something I don't understand. It would have been english without the bug and if it's english without the work done. So why bother? Is your goal a "100%" string somewhere or an italian desktop?
I agree with that. I doesn't make chage as it is added strings and it doesn't change anything but statistics. What is anoying is when you change dozen of strings to fuzzy (for changes such as minor typos) very late in the stage. I think (but not sure) that is was what happened last relaese with knetworkmanager.
For small team, when we cannot goal to 100% translation due to lack of translators, we try to focus first to the user experience. So we have to make choices and we skip for later things such as yast modules to make servers or other very advanced features to focus on the desktop. So for us it's a very bad thing if proeminents thing in the Desktop are shown in English such as "Destkop folder" on the deskop's folder view or things similars.
I think the error was not to add these strings earlier (if it was possible).
Greetings,
Djan
E.g. we could branch out yast now and freeze it for openSUSE, but then we would also lack all the fixes done now. So basically we decided to go for more fixes and a possible lack of translations at some points. But as we did with past releases, we'll ship translation updates where it makes sense.
I admit 11.1 has a very long freeze period, so it is a sort of exception. However, I tend to think that a branch at a certain point (not the last week of the development) would improve things. Of course this would require a different planning of the development phases.
For example, in the years I spent around openSUSE, I always noticed that changes are done from the middle of the alpha stage to the beginning of the beta stage, while the first alpha's are relatively unchanged. Shifting this back would allow more changes and fixes in the "second part" of alpha stage, and the beginning of beta stage, allowing for a real hard feature freeze at some point in beta phase. I would also stop
Well, alphas see a lot of underlying changes that make it very often even impossible to develop against them. And usually the developers are blocked with other products during the alpha phase. But beta1 is really the point in time where the developers submit new features to the build, adding the strings. Then someone actually tests the beta and we find reasons to add more strings (just read opensuse-factory to spot 'well, just add a checkbox or a popup - it's just beta4').
The problem is, as said earlier, easy to fix if all you care for are translations: just don't change anything. But I'm afraid, for me, it's just one aspect out of many. We're trying constantly (and when I say we I mainly mean Karl and me I'm afraid :) to find ways to make it as easy as possile for the translators. But if you then complain that we make strings translatable that weren't in earlier betas, I fail to understand what you're up to.
I'm open to a discussion on how to improve things, but I'm afraid the things are not as easy as you may think. There are cases where I don't understand why they are still done either, but we will clarify them. PackageKit and yast2-support are two cases that souldn't be in lcn by now IMO (but then again, I was offline for 9 weeks).
Greetings, Stephan
To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org
Hello,
Jean Cayron skrev:
2008/10/31 Stephan Kulow coolo@suse.de
Am Donnerstag 30 Oktober 2008 schrieb Alberto Passalacqua:
Still, I think it should be refused because that translator gave more work to everyone else in the translation teams without consulting them.
This is something I don't understand. It would have been english without the bug and if it's english without the work done. So why bother? Is your goal a "100%" string somewhere or an italian desktop?
I agree with that. I doesn't make chage as it is added strings and it doesn't change anything but statistics.
wondering: if those strings do get translated and submitted, even if it's after the disks are out, do the translations that do exist get downloaded along with any updates at that point in time, e. g. during installation or later via Yast, subject to language settings in the system?
I can't remember noticing this, but I've been out of the loop a bit lately.
If this doesn't happen, I think it definitely should, especially since the installation procedures include a step to look for updates over the Internet.
(BTW, tried installing 11.0 on my daughters computer a few minutes ago, it failed abysmally sine Yast can't keep things apart if there's one DVD-ROM and one CD-RW unit in the computer... :( - hope it's been fixed)
What is anoying is when you change dozen of strings to fuzzy (for changes such as minor typos) very late in the stage. I think (but not sure) that is was what happened last relaese with knetworkmanager.
For small team, when we cannot goal to 100% translation due to lack of translators, we try to focus first to the user experience. So we have to make choices and we skip for later things such as yast modules to make servers or other very advanced features to focus on the desktop. So for us it's a very bad thing if proeminents thing in the Desktop are shown in English such as "Destkop folder" on the deskop's folder view or things similars.
I think the error was not to add these strings earlier (if it was possible).
I agree, and I think everyone should get the benefit of doubt first off, since a software release is always a game of moving targets for everyone involved.
BR, Gudmund
2008/10/31 Stephan Kulow coolo@suse.de:
Am Donnerstag 30 Oktober 2008 schrieb Alberto Passalacqua:
The strings were added after a translator testing the beta asked for the strings to become translatable. Only a very small part of it is KDE 4.2
I think I know who asked for that. ;-) Still, I think it should be refused because that translator gave more work to everyone else in the translation teams without consulting them.
This is something I don't understand. It would have been english without the bug and if it's english without the work done. So why bother? Is your goal a "100%" string somewhere or an italian desktop?
E.g. we could branch out yast now and freeze it for openSUSE, but then we would also lack all the fixes done now. So basically we decided to go for more fixes and a possible lack of translations at some points. But as we did with past releases, we'll ship translation updates where it makes sense.
I admit 11.1 has a very long freeze period, so it is a sort of exception. However, I tend to think that a branch at a certain point (not the last week of the development) would improve things. Of course this would require a different planning of the development phases.
For example, in the years I spent around openSUSE, I always noticed that changes are done from the middle of the alpha stage to the beginning of the beta stage, while the first alpha's are relatively unchanged. Shifting this back would allow more changes and fixes in the "second part" of alpha stage, and the beginning of beta stage, allowing for a real hard feature freeze at some point in beta phase. I would also stop
Well, alphas see a lot of underlying changes that make it very often even impossible to develop against them. And usually the developers are blocked with other products during the alpha phase. But beta1 is really the point in time where the developers submit new features to the build, adding the strings. Then someone actually tests the beta and we find reasons to add more strings (just read opensuse-factory to spot 'well, just add a checkbox or a popup - it's just beta4').
The problem is, as said earlier, easy to fix if all you care for are translations: just don't change anything. But I'm afraid, for me, it's just one aspect out of many. We're trying constantly (and when I say we I mainly mean Karl and me I'm afraid :) to find ways to make it as easy as possile for the translators. But if you then complain that we make strings translatable that weren't in earlier betas, I fail to understand what you're up to.
I'm open to a discussion on how to improve things, but I'm afraid the things are not as easy as you may think. There are cases where I don't understand why they are still done either, but we will clarify them. PackageKit and yast2-support are two cases that souldn't be in lcn by now IMO (but then again, I was offline for 9 weeks).
Greetings, Stephan
Hi,
One think that could help is to have a defined schedule for translations, considering many "translations rounds" as betas/rcs or something more usefull. In this release, we have only a start date and a "1st localized release" date, nothing more...
We should have something like that:
1st translation round - between alpha3 and beta2 (to appear in beta2) - ~30days 2nd translation round - (after the testing in beta 3, adding missing strings, new features strings, etc) ~20 days 3rd translation round - between RC1 and RC2 (only last minute strings nothing cosmetic) -10days
And to help translators, when adding strings from others projects, make us now, so we can see if any work have been done in upstream to help our work, like in kde4-openSUSE.po , some strings (the biggest ones) are from: http://websvn.kde.org/trunk/l10n-kde4/$LANG/messages/kdegraphics/libkdcraw.p...
Regards,
Luiz
Am Freitag, 31. Oktober 2008 15:28:26 schrieb ¡ElCheVive!:
And to help translators, when adding strings from others projects, make us now, so we can see if any work have been done in upstream to help our work, like in kde4-openSUSE.po , some strings (the biggest ones) are from: http://websvn.kde.org/trunk/l10n-kde4/$LANG/messages/kdegraphics/libkdcraw. po?view=log
didn't know that, thanks
Regards Michael
translation@lists.opensuse.org
-
Alberto Passalacqua -
Gudmund Areskoug -
Jean Cayron -
Michael Skiba -
Stephan Kulow -
¡ElCheVive!