>> That would mean that any new package uploads in Ubuntu would refresh
>> current translations with upstream provided ones, if a translation
>> team chooses to use that option. However, that can happen next month
>> at the earliest (and I am not making any commitment yet, this has to
>> be discussed within the team), because, even if a simple change, it
>> will involve changes to the core piece of our code, thus needing a lot
>> of testing.
>
>Would this be language-wide or could you implement this based on package
>sets? Because I guess no language will be willing to check this as a
>global option but rather for good-maintained package-sets
>(GNOME/KDE/freedesktop).
I think this is a really good solution. I agree with Johannes that it would be a good idea to enable this feature based on some package-sets, essentially they should probably be based on upstream source i.e. one for GNOME upstream and so on, but that's all details which can be worked out later.
>> Doing this will, of course, limit our time on other interesting things
>> we can work on, but I am sure GNOME as an upstream doesn't really care
>> about that.
>
>I think you are wrong here as most people really take care on the
>end-user. I cannot speak for GNOME (not even for gnome-18n, you are the
>spokesman ;-) but there are lots of interesting things I would like to
>see in Ubuntu/launchpad.
>Anyway, lets consider this won't be in place for hardy (= GNOME 2.22).
>That's no problem as most of the big problems could be solved by
>team-reorganizations. But would it be possible to to implement the
>"overwrite" policy (instead of a "lock" policy) for Hardy + 1 (= GNOME
>2.24)? Personally I think that would be a reasonable time-frame for
>testing, getting feedback, discussing on GUADEC, etc.
I agree with Johannes on both points.
On another note. You guys were talking earlier about how to get information out to the masses. May I suggest that this feature is made in such a way, that when a user enters the translation page for a package, which is one of those that have strings that will be overwritten, then the first thing that he sees is a big red flashing warning-light. This warning should explain that if he wants to contribute to this package, he should first translate any remaining strings upstream after coordinating with the upstream team (contact information and so on should be given) and then after the complete upstream translation has made it into LP then he can translate any remaining strings added by Ubuntu specific patches in LP, if such strings exist.
This would not only help to better explain the "best" way to contribute but would also make sure that any volunteers that come in from the Ubuntu community is properly greeted and not left not knowing how to proceed if they want to contribute.
>> That would mean that any new package uploads in Ubuntu would refresh KDE/freedesktop ).
>> current translations with upstream provided ones, if a translation
>> team chooses to use that option. However, that can happen next month
>> at the earliest (and I am not making any commitment yet, this has to
>> be discussed within the team), because, even if a simple change, it
>> will involve changes to the core piece of our code, thus needing a lot
>> of testing.
>
>Would this be language-wide or could you implement this based on package
>sets? Because I guess no language will be willing to check this as a
>global option but rather for good-maintained package-sets
>(GNOME/
I think this is a really good solution. I agree with Johannes that it would be a good idea to enable this feature based on some package-sets, essentially they should probably be based on upstream source i.e. one for GNOME upstream and so on, but that's all details which can be worked out later.
>> Doing this will, of course, limit our time on other interesting things ations. But would it be possible to to implement the
>> we can work on, but I am sure GNOME as an upstream doesn't really care
>> about that.
>
>I think you are wrong here as most people really take care on the
>end-user. I cannot speak for GNOME (not even for gnome-18n, you are the
>spokesman ;-) but there are lots of interesting things I would like to
>see in Ubuntu/launchpad.
>Anyway, lets consider this won't be in place for hardy (= GNOME 2.22).
>That's no problem as most of the big problems could be solved by
>team-reorganiz
>"overwrite" policy (instead of a "lock" policy) for Hardy + 1 (= GNOME
>2.24)? Personally I think that would be a reasonable time-frame for
>testing, getting feedback, discussing on GUADEC, etc.
I agree with Johannes on both points.
On another note. You guys were talking earlier about how to get information out to the masses. May I suggest that this feature is made in such a way, that when a user enters the translation page for a package, which is one of those that have strings that will be overwritten, then the first thing that he sees is a big red flashing warning-light. This warning should explain that if he wants to contribute to this package, he should first translate any remaining strings upstream after coordinating with the upstream team (contact information and so on should be given) and then after the complete upstream translation has made it into LP then he can translate any remaining strings added by Ubuntu specific patches in LP, if such strings exist.
This would not only help to better explain the "best" way to contribute but would also make sure that any volunteers that come in from the Ubuntu community is properly greeted and not left not knowing how to proceed if they want to contribute.
Regards Kenneth Nielsen