On Thu, 2011-10-13 at 12:16 -0600, Tim Flink wrote: > On Thu, 13 Oct 2011 07:39:12 +0530 > A S Alam <apreet.alam@xxxxxxxxx> wrote: > > > ਵੀਰਵਾਰ 13 ਅਕਤੂਬਰ 2011 07:22 ਸਵੇਰੇ ਨੂੰ, Adam Williamson ਨੇ ਲਿਖਿਆ: > > > On Thu, 2011-10-13 at 07:14 +0530, A S Alam wrote: > > > > > >> I want to add that although translation available for some > > >> language need not to be blocker, but string should be i18n, so > > >> that if language teams want, then they can do translation. i18n > > >> failure case [1]. > > > > > > You mean, you think we should also require all install / boot / > > > login strings be available for translation? > > > > no, not all, but anaconda and gdm should have all strings (grub or > > boot can not include in this criteria). > > Just to make sure that I'm following you, you're proposing that we add > a release criteria for Fedora that would require desktop managers (or > whatever gdm, kdm etc. are called) and anaconda to have strings > available for translation. > > If I am understanding correctly, I'm not sure it's our place to be > making requirements like that for upstream components. Could we try > to do that? Sure, we could try anything we wanted. Would it > work? Maybe, but I kind of doubt it. Should we do it? No, I don't think > so; I'd rather not even approach the path of making feature demands of > upstream projects - "add feature X or we can't release!" just has a > bad sound to it. I don't think it's a feature demand, exactly, as I'm fairly sure gdm is already supposed to have all strings available for translation, and if one isn't, that's a bug. Ditto anaconda. So it's more ensuring that an existing feature is actually implemented. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
