Hi Josep, (stripping most CCs)
Today at 18:46, Josep Puigdemont wrote: >> Having 100% translation is useful for more things than >> show-off: >> - it's easier to notice new strings/string changes! >> (this is important for the same reasons we have a string freeze at all) > > I'm not following here. It's actually when the translation is not 100% > done that one realizes that there are new strings to translate. Exactly. And if we introduce new string which might end-up untranslated, I'd either have to translate it, or I'd have to use 99.87% as a marker. And I don't want to remember such spurious figures, since I consider translation of this string not important enough. >> Legalese is pretty hard to translate, and that's why I didn't approve >> the change (i.e. it's likely to skew the stats). And it's commonly >> binding only if it stays in English (at least for GPL, even if we >> generally mark such passages for translation). > > That's probably true, but then the question would rather be if this > string should be marked for translation or not (you do ask to be > marked for translation in 2.16, though). Explained with the remark: "even if we _generally_ mark such passages". I am not a lawyer, and it is common practice in Gnome to mark them, so I am simply not changing anything. > I don't get this, what does make it mean that "our process is a bit flawed"? > How do you detect string breackages today? I watch one of the 100% (or nearly) completed translations for changes, and check the string count in my weekly stats e-mail (I generally check it only once a week), i.e. I basically look at http://i18n-status.gnome.org/gnome-2.14/top.html and the less string freeze breakages we get, the less I have to browse from there. > As a [probably naive] proposal, what about making a pot file just > after string freeze, and then generate a new one daily, and then > compare both to see if there are changes? (comments should be out, of > course) It sounds fine, you are welcome to implement it: I can give a hint or two if you need it. :) (we also need ability to mark another revision of POT file as "frozen" one, since we do approve some freeze breakages) It shouldn't be too hard to even add automatic mailing to one of GTP spokespersons who'd have to do the investigation manually then. :) I'll be happy to put it then on one of Gnome servers as well, and run it as a cron process. I don't have the resources (bandwidth to do full CVS checkouts, time or desire either :() to perform such check manually. > I don't know what you mean with this, but many strings (maybe most of > them?) are rarely seen (gconf stuff, tooltips, etc), yet if they are > not translated, they will make some languages be not supported... Again, it's a flaw in our process: we measure "supportedness" only by the string count in the stats. Another reason to not allow string freeze breakages, and to allow putting in some strings untranslated which are rarely seen. Ideally, we'd have prioritised translations, and we'd evaluate supportedness only by most important messages (i.e. gtk+/po-properties would be completely excluded, as well as most parts of gnome-applets/po-locations, and many messages inside all the other modules). But we are not there yet :( > Anyway, my point was that if you let a new string in, you should allow > translators to translate it, else leave it out. I might be wrong > though. No, allowing it in is a service to developers, while not harming translators (by skewing their stats, perhaps having their languages end up unsupported): localisation won't be complete, but in practice it's not important, since it won't be allowed for visible messages. Or do you disagree? As I said, there are many flaws in our process, but I don't have the time right now to go around fixing them :( Anyway, Guilherme proposed alternative solution, and I support him in carrying it through. :) Cheers, Danilo _______________________________________________ gnome-i18n mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-i18n
