By xbro on

今いくつか翻訳試してみました。印象としては、訳語統一は、翻訳提案をコミット（アドミン？）する人達でルールやガイドラインがあればいいのではと思います（できるだけ短縮、省略された文章をどう作るか、カタカナをどう解りやすい範囲内で使うか、その度合い、”。”を文章の終わりに付けるか？など）。ローカリゼーションも人それぞれスタイルがあるでしょうから。

翻訳活動全体の統一感を出すにはご存知のようにそこがポイントですが、その統一感を出せる人数が多ければ多いほど（チーム作業）、コミット作業が大人数でのローカリゼーション作業全体のボトルネックにならないと思います（ボトルネックになるのは明かです）。しかし、ここは最初からまともな結果が求められる中（Takafumiさんの貢献により）試行錯誤をしながら地道にやって行くのも一つの手だと思います。プロとしてDrupalを使用してる人達にはたまらない事ですが一時的に現在の状況を考慮すると仕方がない事なのかもしれません。鎖国がとけ、幕府が混乱になり、いずれ明治時代に向けて調整があったみたいに、日本Drupalの明治時代到来ですか？

*************************

しかし、私はアドミンではないこともあるのかもしれませんが全然違う所を気にしてます。限られた人数で何万というstringをランダムに作業していくのは果たして効率がいいのかということです？できれば既に何人か翻訳を試みたのであればそれを表示してもらえれば、翻訳が７、８回重複して後半ページは誰も翻訳してないとかそういう状況を避けられると思います。翻訳attemptを閲覧して、みんなで投票できたら尚更いいと思うのですが、そういう機能は参考にまで聞きますがないですよね？

スコットより

p.s. 私は日本語と英語都合に合わせて使いわけるのですが、母国語はどちらかというと英語ですが家族は全員日本人です。両言語で常に書かない理由は面倒だからなだけで、必要な時しか両言語で書かないのでご了承下さい。

Due to reasons that always posting in both languages is too much work for me, plus I writing in Japanese seems to create misunderstandings, I only post in one language or the other unless it's necessary to post in both. I prefer writing in only English for operations, fyi. Scott

Groups audience: 
Japanese team

Comments

Antoine Lafontaine commented

I think I agree with you on this.

two ideas I would like to also ask to consider:

1. voting on each (or even a group) of translation might be quite a burden time wise and I feel (and it's just an opinion without much experience to back it up) that this would slow down the process of improving the overall translation (in number of translated string and also maybe in quality). If people do agree with me on this (no obligation of course) than I feel we need a more flexible (agile) way to process translation suggestions. Since the group has been opened about 1000+ strings have been suggested. We do not have a common translation dictionary yet (an none seemed to be used by Takafumi's team since they were working in a small group) so we also need time to shape this up. Waiting for that dictionary to be all shaped, even partially, might just take too much time.

So, my proposition is the following: let's make it possible for any admin to commit any string that is suggested that does not have any Japanese equivalent yet (of course, the admin that commits might just refuse a suggestion if it is evaluated has wrong). Then any strings that already has a translation and has a new suggestion pending should be debated. Using those two simple rules, I believe we could have most of the pending suggestions committed. (for the debating part, we should discuss it in another thread, maybe)

Then the pending problem would still be making sure that we have a high quality translation. My opinion on this is: do not try to always commit perfect translations; make it easy to commit translations and make it easy to be able to recommit any new suggestions. The localization server make it really easy to work like this. Another good point is that we could use both strengths of our community members (which are a mix of Japanese and non-Japanese people) having English speaking people suggest some basic Japanese translation and then Japanese members would just try the new committed translation and re-suggest improved or corrected translations; this lets non-English speaking Japanese members still be able to contribute to the translation effort.

Of course, I know some might say that this will make it possible for some people to download less than perfect translation packages, and they would be right, but my take on this is that it is better to have some imperfect Japanese be published than just the all English version of a module. And if those published strings are so bad, it might even get some new people to consider joining the translation group to help improve the translation quality. I fell this would be good overall.

And when we'll have more translated content than non-tranlsated content, the process will change naturally to have more debate around which suggestions we'll commit and those we need to rework. This will be a bit later, so we'll have some time to work and make the rules for such debate (and maybe voting and all)

2. I also agree with you that posting in both languages is a lot of effort so letting all members post in their language of choice is the best option. We can then also make sure that important messages or important decision would be available in both languages.

Thank you for taking the time to consider my ideas.

xbro commented

Rather than flooding the L.D.O pages with minute details of localization, is there a need to start a g.d.o/ Japan localization group by any chance?

I clearly see a need for an open group for discussions, it might get nitty gritty and I question if L.D.O is the place to do it.

Antoine Lafontaine commented

This is a group (look at the breadcrumbs up there). discussion should be done here. no need to ask people to look for threads in a different place I feel.

xbro commented

I was thinking of..

for example someone wants to suggest that the word "image" should not be translated as "イメージ", and should be translated as "画像".

Double checking, but is it really efficient to discuss those kinds of details here in many different threads?

As discussions on the way words are translated and the actual translation could flood the discussions here and I assume naturally we want to keep discussions here on big topics, or we don't want to miss the big topics.

Imagine if for example I posted 10 threads for questions or debating on the details of translations as I can probably process hundreds/day, and aiwata posts one big discussion on changing the settings of this group, it makes no sense to have those discussions all jumbled up together.

If the discussions could be seperated, yes it makes sense to have the discussions here. But if they're gonna be all presented together, I say lets have the detail discussions some where else. As keeping information organized is basics, even for working out some unified style in translation we want to keep those discussions together. not jumbled up with other topics.

If we're not going to be hotly debating, and only few threads are expected then it could be processed here. but if we're really gonna start discussions, can l.d.o really sort the information appropriately?

I'm a database guy so when I see all kinds of information jumbled up together it makes me want to sort. It's one of my nature, but anyways if I'm making sense can we consider separating the discussions, and a dedicated g.d.o group for specific discussions is just one suggestion.

pineray commented

訳語の選定とその他のトピックを同列に扱うのは確かに無理があると思います。
ただ、だからと言って翻訳に関する議論を g.d.o で行うのはどうかと。
今現在のメンバーは g.d.o の方々がメインとなっておられるのでしょうけど、そもそも l.d.o と g.d.o は別物ですし。
情報を一か所に集めるという点から言うと、翻訳に関することは l.d.o に集まっている方が自然ではないでしょうか。

とか言いつつも、訳語の選定作業に関してはどこか別の場所で行った方が良いと思われます。
機能的にこのサイトでは力不足ですし（投票もありませんしね）。

aiwata55 commented

@PineRay さん

fuji@drupal.org さんが言いたかったのは，g.d.o./japan でスレッドを立てるのではなく，新たに g.d.o. 内に Japan Translation グループを作り，そこで作業してはどうか，ということだと思います。

g.d.o./japan 内で作業を行うのは，PineRay さんがおっしゃるように反対です。僕が再三コミュニティに対して訴えているように，l.d.o./ja と g.d.o./japan とは全くの別物で，l.d.o./ja は g.d.o./japan の影響を受けるべきではないと思います。

P.S.
g.d.o. というと，http://groups.drupal.org のこと，g.d.o./japan というと，http://groups.drupal.org/japan のことというふうに，用語の統一をしていかないと，コミュニケーションが難しいですね。まだ始まったばかりの共同作業ですからこういう混乱が起きるのでしょうが，がんばって共同作業の基盤を作っていきたいですね。

pineray commented

@aiwata55 さん

> fuji@drupal.org さんが言いたかったのは，g.d.o./japan でスレッドを立てるのではなく，新たに g.d.o. 内に Japan Translation グループを作り，そこで作業してはどうか，ということだと思います。

なるほど。しかしそうであってもグループが増殖するのはどうかと。
グループとしてはこの l.d.o./ja にとどめ、投票やWikiといった足りない機能を他で補う方向が良いと思います。
そして l.d.o./ja 内にそれらのページ（またはサイト）への案内コンテンツを作成し、Sticky で表示してはいかがでしょうか。

あと、 g.d.o. や l.d.o. を特に意識せず使っていました。
g.d.o. と g.d.o./japan、l.d.o. と l.d.o./ja をきちんと分けるべきでしたね。

それにしても、Notification が全く動作していないんですが、僕だけですかね？

xbro commented

はい、g.d.o. でl.d.o作業専用のグループを作成という案でした。

Wikiと投票はg.d.oに既にあります。g.d.o.自体は遠慮なくグループをいくつでも作れるように出来てると思います、g.d.o委員会の審査はありますが、グループ名は何回でも変えられます。コミュニケーション用のツールとしてはl.d.o.の機能より長けていますので参加する壁も低くできると想定しています。

この策を使うのであれば、どう（purpose specificの）g.d.o.グループを翻訳に使用するかはっきり決めれば、そこまでl.d.o.一ヶ所にこだわる必要はないと思います。私は ”の” や ”。” を入れるべきかというような細かい会話や、難しい翻訳に人数で磨きを掛ける作業は今の所g.d.o.の機能が適してると思います。

本来私は何でもやたらと”サイト出そう！”と提案するんですが別にg.d.o.で十分であればg.d.oでいいです。個人サイト運営してたら、部外者だったら中々参加しにくいですよ。

l.d.oの目的は必ずしも今l.d.o上でのメンバーそれぞれの翻訳効率を上げるのが目的では無さそうなので、工夫しても良いと思います。l.d.oは今のところもっとMacro的な考え方ですよね。そして本当に重大なスレッドだけl.d.oで掲示する方が今のところは良いと思います、少しでもg.d.o.機能に近づけばあまりg.d.oで作業してる意味ないですが。

pineray commented

よくよく考えてみると、 l.d.o. では機能的に不十分なため他のサイトで作業するということは、そのサイトが g.d.o. であっても別のものであっても大した違いは無いなと思いましたので、前言を撤回し、 g.d.o. に新しく翻訳チーム用グループを作成する意見に反対しないことにします。尻軽ですみません。

なぜか g.d.o. にログインできなくなっているので（同期の申請はしているのですが ...） g.d.o. の機能が分からないのですが、まあ使いづらかったり他に良い選択肢が出たら切り替えれば良いですかね。

他の方の意見も伺いたいところです。

pineray commented

僕の意見は基本的にAntoineさんとほぼ同じです。つまり、とにかく訳語の suggestion を受け付け、全く新しい訳語であればすぐに承認し、重複があればその都度審議する。

以前のようなTakafumiさんと僕くらいの規模であれば、統一された訳語を元に翻訳を進めていく形がとれたのですが、不特定多数の参加者で一斉に翻訳するとなると、そうした手法では弊害が大きくなりますしね。あと、このサイトの承認機能をちょこっと見てみたのですが、suggestion が多くなると、ひとつひとつ確認して承認するなんて現実的に無理です（← ちょっとここ矛盾してますね）。

なので、対訳表や訳語の統一ルールを整備しつつも、それを訳語に反映させることについては、訳者それぞれの良心と努力に依存するしかないと思います。翻訳に問題があったら、それを見つけた人が suggestion という形で報告するということで。

xbro commented

Is there a suggested best practice for translating? As I'd rather download a large text file and upload the translations in a bulk? This way I also get to improve upon translations and triple check before suggesting.

From my non-admin view, I have no idea which words have been translated, whether previous suggestions are good in order to assess taking time to translate. I'd probably forget which words I translated on-line as I progress and may suggest other translations which is redundant. And I'd like to avoid redundant work.

I'd rather like to approach this in an organized manner such as working on specific number slots etc.. because with the numbers we have now isn't going to process 170k strings that fast, and my assumption is that even if the group were open we won't get hundreds of members joining any time soon.

I would like access to what the admins see in terms of translations, that would allow me to work more efficiently, but I have no interest in having the ability to change group settings. Can a new kind of translator role be created, so that translators can see more by any chance.

Making a fast translator like me just RANDOMLY translate at 170k strings not knowing what's going on, what others have done, is not something I'm thrilled at in terms of efficiency and organization.

The admins having have to go through a number of suggestions for just one translation is least of my concerns (I would try to read all of them btw.) and is also assuming we've already got thousands translating, but I would be concerned if I don't know if I'm wasting time translating a string if a good suggestion had already been made.

If there are going to be lots of translators as we intend, I suggest we sit down and try to address this translating efficiency issue from the non-admin perspective because I don't think anyone believes we want to approach 170k strings randomly. systematic approach I suggest, how? we need to talk about it.

Antoine Lafontaine commented

I think the two points you make in your post are the following:

1. There is a need some kind of way to process the suggestions (preferably not a random one - concerns only admins?)
2. There is a need for a way to let people know what strings are already translated.

I agree on both of those, but please correct me if I misunderstood you.

As for my take on this:

1. As I said it before, we need to be able to process the suggestions as fast as possible and I believe this will make #2 easier to handle. My take on this at this point is, since the maintainer doesn't seem to be interested in doing any commits for the time being, we just commit any suggestion that has not been translated yet. The ones that are already translated will need to be debated (to be discussed a bit later if we can agree on this basic rule). If one follow my reasoning, we will eventually end up in a situation were most string are translated to a certain level and then new suggestion will need to be debated, making the first rule almost non-applicable (for people afraid too many translations might go in resulting in poor quality translation) Then we come to the most important part, how can non-admin know the status of the translation: let's go to 2.

2. If most suggestion gets committed quickly, any person installing drupal and/or any translated module will be able to "test" the translation in test drupal site and/or export a module specific strings for inspection/revision in an external tool (My goal is not to explain how to use an external tool, so bear with me on this for now) I think this also answer how it is that someone should go about and organise it's workflow for translation when she wants to make more than just a simple one word correction (which will also be possible with the tools available in Drupal) For now I do not believe we need more organization and decide who and what will need to be translated and in what order. Of course, we will need to also think about those things and I believe it will be easier to see patterns and problems if we actually start doing some actual commits and corrections and all. I think it is also possible to search and see all the strings on l.d.o for admin and non-admins. (please again correct me if I'm wrong on this one)

The other thing that will be needed is some explanation on the many ways there are to get the latest translation files or parts of it and setup a test drupal site to work and test/check translations and all.

I know that I do not propose solutions to all the problems that will come up the road, but for now I think we have to deal with our lack of knowledge of the process and try to at least start to work on pilling some experience. Takafumi or PineRay might have other ideas to propose but like PineRay said in his post above he seemed to agree that working with l.d.o system would probably need and approach like I propose.

Of course, if you have any idea you would like to propose (and do not mind posting it here or at least link to it here) this would be very helpful I believe.

xbro commented

yes, non-admins can see all the strings, fyi. But not the status of translation of each word such as all the suggestions awaiting for selection, which I feel is a function needed that will definitely cut down on redundant translation efforts.

I agree with your approach on taking an easy and fast approach to accepting the suggestions for starters.

And I first thought we were dealing with 17000 strings, but now realize we are dealing with 170k strings, which I feel now that dealing with the shear amount of strings is the largest bottleneck than processing the suggestions which seem are around 1000 suggestions.

I haven't put too much time in thinking about this but would like to put forth 2 approaches, in attempts to organize, which I still feel is necessary (come on now.. 170k strings!?).

1. First suggestion is an added feature which this group may have to ask the maintainers of l.d.o. to make this feature available. But I feel very strong about this, and I think it will help a lot of other groups progress too. The basic member of l.d.o. should be able to view all the suggestions made on each string, so that they can judge themselves if they want to spend time translating that string. I'm curious what the admins see, and how others translate too, and suggesting that the regular member be able to see just one step short of having access to the commit features. If it is really inefficient for the admins and they can only see suggestions one by one by clicking, this is something that should be improved and requested that they be able to see suggestions 50 at a time, or even have a feature where the translations feature will lock after receiving 50 suggestions and alert messages issued etc..

2. This is where we may disagree, I don't feel as strong about this like the one above. It's just an image that popped up, you know there's a trooper gene ingrained somewhere in me. OK, 170k. We may want 17 admins for each 10 thousand, and they are in charge and responsible for their 10 thousand strings. They can allocate project leaders etc.. start teams and go at the strings their style and share their strategy with others, and we have monthly meet up to share ideas.

Another way is we as a group decide we will focus on installation, allocate project leaders and teams and go hacking away, and then move onto next section. Some focus surely must be essential in producing some sort of worth while results.

Anyways, my main suggestion on this was "Project Management" and "Teams", for 170k. If not some sort of focus, a flag pole (for example announcements such as this week will be translations 12000~15000 etc..) so that we can congregate and focus.

xbro commented

note, idea1. above will cut down on time on developing a uniform localization style developed by the group as we will all have a more aggregate view on how the suggestions are accepted, and how others are translating.

It will enable all members in this group (not just admins) to understand how and what kind of suggestions are being accepted. And who is not good at translating... , who is doing what, and will enable us to coordinate team efforts working on top of other peoples work like you suggested some where (for example I'm good and fast at coming up with first draft, but others are faster and better in coming up with complete work).

Also even when a suggestion is committed, at least for a while the alternative suggestions should be left in a sort of queue, in case other admins want to over-ride the original commit (how will you guys over-ride??), or someone wants to come up with a better translation.

If things aren't so obvious on which suggestions to commit, a vote should take place (how?).

Admin roles should be split up into admins and commit roles. We probably want as many people doing commits, but not as many having access to admin features.

I hope the above brainstorm like comments will become of some use in the near future.

Oh, and a wiki page for detail discussions on translation issues might be good, rather than having tons of threads.

aiwata55 commented

グループのダッシュボードページに，日常の翻訳作業で頻繁に使うであろうコンテンツと，当グループに新規参加した人に役立つであろうコンテンツを掲載するスペースを作るため，l10n-server-ja タグを削除しました。

当コンテンツがダッシュボードに掲載されるべきと思われる場合は，お手数ですがタグを付け直してください。