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 -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org