皆様 小林です。こんにちは。
3.1でUIの大きな変更を機に、開発者とL10n(私達)とのコミュニケーションスタイルについて、幾度となくテーマを変え、議論されていますね。 最近のreleaseリストでのAndreの問題意識は、割合、L10nの困り具合を具体的に例示していると思い、引用しておきます。 別のメールでは、Sophieがreadmeの僅かな更新もL10nには翻訳バグにつながり、開発者との緊密な情報連結が必要と主張しています。 これら開発者とL10nとの、コミュニケーションスタイルについて、ESCの場で、議論され改善されることを期待したいと思います。 リリースの最終工程の翻訳段階でバグだとしてIssueを上げるのは、通常のソフトウェア開発では最もてもどりが大きいプロセスですからね！ いまや、ワードカウントは、凄まじい翻訳規模に及んでいますね。何か改善提案があればjaからL10nに上げて、ESCにインプットしていくことも有効かもしれません。 皆様のご活躍に感謝しつつ、情報共通まで。 (ワードカウント例示) E.g. for 3.1 each l10n team had to translate ~9,000 Words for UI, 18,000 for Help. Thanks, Katsuya ---------- Forwarded message ---------- From: André Schnabel <[email protected]> Date: Sat, 14 Feb 2009 16:25:19 +0100 Subject: Re: [releases] Re: [l10n-dev] changed strings in 310_m1 To: [email protected] Hi Frank, Frank Schönheit - Sun Microsystems Germany schrieb: > > "dbaccess" caught my attention here, that's one of the modules my team > works in ... > :) > We might have a communication problem. In my understanding, changing > resources so that the effective strings stay the same, but maybe > identifiers change, or strings are moved within files, or such, is an > alloed change. > > Also, the tool which we developers are required to run before passing a > CWS to QA ("cws_localize --no_checks") checks for "changed strings", and > "word count". To my best knowledge, only the latter is relevant (and > must be 0 after UI/translation freeze). The former might not be 0, but > this was never considered a problem. > This really looks like a communication problem. IANAD (I am not a developer) but I cannot find a reference to this tool or to this rule serching the ooo website and the wiki. So even if the tool would work correctly ( Pavel's answer suggest something different) it is not very helpfull, as nobody can learn about it. > If this *is* a problem for translation, then I think we should urgently > communicate this to us developers. I am quite sure nearly nobody knows this. > Hmm .. at the moment I cannot tell if it *is* a problem. I'd expect it to be a problem. To be sure, I would need a build with current localization included to verify this. But at the moment we don't have such a build. To me it seems, as if l10n is not only the last but also considered the least piece in product development. E.g. for 3.1 each l10n team had to translate ~9,000 Words for UI, 18,000 for Help. We have at least 15 localizations at 100% UI - means each non translated string will be a regression for those localizations. In addidtion to the "new" trings we constantly work on removing l10n bugs and improving the localisation. To be able to do this, we need to test our translations in the product - but we get a version for testing only short before RC phase. So l10n teams are not able to fix bugs before a relase (unless we start to quarrel and try to declare "our" bugs as stopper issues). Having a lot of stoppers is no real fun - for no one of us. I'd love to be able to identify l10n bugs earlier but although this has been discussed several times we still have (almost) the same situation. I'd like to see this discussed in the ESC: - how can we prevent that UI changes come in at a very late time (normally no UI change must happen after UI freeze without discussion - and even removal of strings is a UI change, as such a removal is relevant for help and localization) - how can l10n teams get access to builds with current localizations right after localizations have been delivered (it was sufficent for me, if we could get access to such bulds via buildbots). --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
