By dokumori on

Drupal 6.19はバグ修正を含むリリースだったので、未翻訳文字列を探してみたところ、２つほど見つかったので翻訳しておきました。（adminのどなたか承認お願いします）

今後、未翻訳文字列を新たに含むアップデートがリリースされた際、すみやかに翻訳・承認ができるようなワークフローの作成を提案します。

リリースごとに担当を決めても良いですし、「早い者勝ち」で翻訳し、訳者がAdminに連絡するなどの方法も考えられます。重要なのは、コアのリリース後できるだけ早く翻訳を提供することだと思います。

ワークフローに関する提案があればコメント欄にお願いします。

==============

Since Drupal 6.19 contained bug fixes, I searched for untranslated strings and found a couple so I've translated them.

I'd suggest that we define a workflow that will allow us to promptly translate / approve new strings when the core containing untranslated strings is released.

We can assign the members to each release or just let anyone translate and have the translator contact one of the admins. The important thing is to provide the translation asap after the core is released.

If you have any suggestions on workflow please leave a comment.

Groups audience: 
Japanese team

Comments

dokumori commented

毎月一人が当番になり、コアのリリース状況を確認するというのはどうでしょう。リリースが行われた場合、当番の人が：

  • 新しい文字列が存在するか確認
  • ある場合、それを翻訳するか、翻訳者を探して翻訳のコーディネーションを行う
  • 翻訳がなされた場合、翻訳を承認するか、承認のコーディネーションを行う
  • 変更に関して l.d.o/ja で簡単なアナウンスを行う

当番は、希望者のみで構成しましょう。権限に関わらず。
たたき台なので、変更／改善してください。

==============

How about assigning a member every month to watch for the core release? When release happens, the person in charge:

  • Confirms whether new strings exist
  • If it does, translate the strings or cooridnate the translation by finding translators
  • When translation is complete, approve the translated strings or coordinate the approval process
  • Make an announcement about the changes on l.d.o/ja

Let's assign the duty to only the ones who wish to volunteer, regardless of the members' permission.
It's just a working draft for the further discussion.

aiwata55 commented

最近はじまった定例電話会議でも提案されたけれど、このアイディアはとても良いと感じています。

どんなにプロジェクトに貢献しようと思っていても、それぞれ日常の仕事と私生活とがあるので、気付いたらつい時間だけが経過するということが良くあります。少なくとも僕はそうなのですが、このように当番制にすることで、当番に当たっている期間中は少なくともこのプロジェクトに関する活動の優先順位が上がり、今までよりも実際に作業することが増えるだろうと思います。メンバーの意識を変え、モチベーションを強化するという点で、このアイディアはとても良いものだと思いました。

また、現在の定例会議はコミュニティに関する相談の機会になっていますが、定例スプリントも開催したら良いと思います。この定例スプリント
・定例会議とは別の機会に持つのか、それとも定例の集まりは月一回で「今回は会議、次回はスプリント」みたいにするのか
・頻度はどの程度が望ましいのか
・顔を実際に付き合わせるのかオンラインでやるのか
などいろいろ検討の余地があるとは思いますが、複数メンバーで集まってわいわい言いながら作業することで、楽しくかつ生産的なコラボレーションの機会が持てれば、参加者も少しずつ増えていくのではないかと思います。

aiwata55 commented
  • 現在は翻訳作業が滞っている緊急事態なので、この問題を解決するための話し合いの場が必要。定例ミーティングの場を、このために活用する
  • ひとたび必要最低限（manager などのロールについて、コミュニティ参加資格、翻訳承認など）のポリシーが定められ、場合によっては役職者の入れ替えなどが行われれば、あとは実際の翻訳作業の出番。この段階では定例ミーティングの一部または多くを翻訳作業に利用する。
  • 以後も、さまざまなコミュニティの問題を話し合ったりするため、たまには会議のための定例ミーティングも開催する。たとえば４ヶ月に１度とか？　話し合うことないよね、ってことになれば、残りの時間は翻訳スプリントに。

ってのはどうでしょう？

yas commented
  • 定例は毎月第4週の金曜日 (JST) 固定。最少催行人数（議事録が成立する）は 2名。MAX 2時間。これはコミュニティがオープンであるためにも翻訳とは関係なく毎月やった方がいいと思う。
  • 四半期ごとに管理者入れ替え（3、6、9、12月の定例で）。これも頃合いを見ながら、半年が妥当だと思えばそれでいいかもしれない。
  • 翻訳スプリントは定例に組み入れることも可能だけど別途時間を設けた方がいいような気もする。でもやってみないと時間間隔がわからない・・今の定例のペースも私にとってはあっという間に時間が経ってしまっていて「もう1ヶ月経ってしまったの！？」という感じなんで。
  • DrupalCon のタイミングで臨時翻訳スプリントをイベントとして組み入れる（「よし、今回はこの部分にフォーカスするぞ！」と、目標を定めてそして何らかの成果を出す）と面白いかもしれない。

ってのはどうでしょう？

aiwata55 commented

定例は毎月第4週の金曜日 (JST) 固定

これまでの参加者の何人かから、日本では月の最終金曜日は忙しいことが多く、できればほかの日がいいという希望があがっていました。第三金曜日ってのはどうでしょう？

「よし、今回はこの部分にフォーカスするぞ！」と、目標を定めてそして何らかの成果を出す）と面白いかもしれない。

目標を定めないと、やったことの評価ができず、結果として達成感が得にくいですからね。目標を設定するのは生産的なコミュニティを育む上でとても有効だと思います。