前のトピックを表示  :: 次のトピックを表示    
	 
	
	
		著者 
		メッセージ 
	 
	
		dynamis  登録日: 2003年5月 22日 記事: 442 
			          
			
		
		
			
				
				  件名: Re: 和訳文書更新の仕方入門?      投稿時間: 2003年9月15日(月) 00:15  
				     
			 
			
				 
			 
			
				暫く見ない間に嵐のように投稿が為されていてビビりました。(^^;
 
オフトピっぽいですが…
 
 
  	  山口 wrote:  	 		   	  dynamis wrote:  	 		  ただやはりいろいろ使い勝手を良くしていこうとすると最終的にはデータも中途な形式ではなく本格的にデータベースに登録した方が懸命です。この辺で素直に現実を受け入れることにして、今月末あたり時間的余裕ができる頃に和訳文書一覧を完全にデータベース化します。そして登録時には既存データから URL をキーに検索をして補完するという形にしましょう。
 
 
取り敢えず山口さんご希望の register ステータスを追加し、入力必須項目については進行状況別にちゃんと分けて処理するように修正を加えます。 	 
 
これなんですけど、だんだん登録のお知らせを出すときの要領が良くなってきていて、大分ストレスは少なくなっています。ですので、今のままでも良くなってきました (^^;
 
 
前にもすでに教えていただいたことがあったかもしれませんが、和訳文書一覧にはどの時点のものが反映されているのでしょう?[完了]と[更新]では登録できないですよね? jt.mozilla.gr.jp がつくリンクを拾ってきているのかな?んー、ここらへんぜんぜんわからないからなぁ(汗  	 
 
 
そうですか、register を加えることは簡単ですので遠慮して頂かなくとも良いのですが、登録というのは文書ステータスとしてはやはり曖昧ですので、必要性がないのでしたら止めておくことにします。
 
# こういったものを追加すること自体は簡単なことですので、必要であれば登録通知用に別のタグを作りますが…
 
 
で、和訳一覧への反映についてですが、まだ全くされていません。
 
現在では無粋な方法で無理矢理検索できるようにしているだけです。(^^;
 
http://moz.skillup.jp/jtp/viewtopic.php?p=571#571 
 
# これは既存の検索インターフェイスを流用しただけなので余分なものも拾ってしまいます。
 
 
入力側の仕様とかは固まってきたのでデータ収集はいつでもできる状況ですが、実際の実装はまだです。ですから、現段階ではステータスにかかわらず一覧には反映されません。
 
# 投稿時にデータに反映するのではなく、反映したいときに投稿中から収集する方式にします。
 
# 間違った入力や返信などをする度に記録されたりすると面倒ですから…
 
 
実装する際には、進行状況報告を投稿から全て収集します。データ収集は単純なURL検出などではなく trans タグをちゃんと識別します。閲覧時に正しく確実に表示できているのを見れば、その識別が正確に行えていると安心して頂けるのではないかと。;-)
 
# BBCode から HTML への変換は出力時に動的に行われています。
 
 
データを集めた上で、原文URL(昇順)-原文日付(降順)-和訳日付(降順) の三つでソートし同一 URL に対しては最終日付のものを出力するという方針です。この辺の処理を柔軟にできるようにするためにもやはりちゃんとデータベースに記録します。既存の HTML のものは bbcode から読み込む前に適当に半手動で SQL の insert 文に変換しまくって、初期データとして格納します。
 
なお、完了したからと行って草稿登録のデータを破棄すると行ったことはせず、例えば初出時を一覧にするとか報告が為された投稿を表示することなどもできる余地を残します。
 
# 実際に実装するまではあくまでも予定です。どうなるかは分かりません。(^^;
 
 
いずれにしても、trans タグを使ったものは全て一覧の元データとして収集される予定です。データ収集の観点からすれば、登録通知時に trans タグを使う必要性はありません。それを必要としてしまうと手間もかかるしどうしても抜け落ちができてしまうでしょうから…
 
 
  	  山口 wrote:  	 		  あー、これはややこしくなりそうなので、特にいらないです(笑
 
もう、全部 dynamis さんにお任せ!8) 	 
 
 
あぁ、逃げられた。(^^;  
			 
		
 
	 
	
		 
	 
	
		山口  登録日: 2003年5月 23日 記事: 2920 
			           
			
		
		
			
				
				  件名: Re: 和訳文書更新の仕方入門?      投稿時間: 2003年9月15日(月) 08:23  
				     
			 
			
				 
			 
			
				 	  dynamis wrote:  	 		  暫く見ない間に嵐のように投稿が為されていてビビりました。(^^;
 
オフトピっぽいですが… 	 
 
僕がこの記事にレスをつけると、完全にオフトピになるので、分割しました。
 
 
dynamis さんがポインタを示してくれた
 
http://moz.skillup.jp/jtp/viewtopic.php?p=571#571  
 
を読んでいてふと思ったことを書きます。
 
 
現在 bbCode の種類は
 
 
 
の四種類となっていますが、ここにある「更新」を「登録」にしてしまってもいいのではないかなと思いました。なぜか?
 
 
単に「更新」とされている場合、この掲示板では「更新が終わった」状態であることはわかりますが、これを将来和訳文書一覧に反映させるようにする場合、おそらく「更新」となるのでしょう。これは「更新済 」なのか「要更新 」なのかが一目ではわかりません。もちろん日付を比較することでわかるのですが、状態欄を一瞥してどういうステータスなのかを把握する点においては user friendly ではありません。
 
 
そこで、こうしてみてはどうかな?と思うのです。
 
 
 
更新タグがなくなり、登録タグになっています。なぜか?
 
 
和訳文書の更新をする際には、原則として、改めて(更新作業のための)予約宣言をしてから作業に取り掛かります。ですから、初翻訳と同じ過程を踏むわけです。なので、その他の過程も始めて翻訳する場合と同様に、「予約 」→「草稿 」→「完了 」でことが足りると思うのです。そこで、管理者の人が「登録 」通知を出せば、流れとしてはスムーズに行くのではないではないでしょうか?
 
 
 
  	  dynamis wrote:  	 		  そうですか、register を加えることは簡単ですので遠慮して頂かなくとも良いのですが、登録というのは文書ステータスとしてはやはり曖昧ですので、必要性がないのでしたら止めておくことにします。
 
# こういったものを追加すること自体は簡単なことですので、必要であれば登録通知用に別のタグを作りますが… 	 
 
というわけで、上のように感じている人もいるということで(僕だけかも(笑)、ちょっと検討してみてもらえますか?
 
#いらないかも、と言ってみたり、やっぱりあってもいいかも、と言ってみたり 
 
#告白しますが、実はいままで「更新」タグをどのような場面で使っていいのか分からなかったんです。  
 
 
 
  	  Quote:  	 		  いずれにしても、trans タグを使ったものは全て一覧の元データとして収集される予定です。データ収集の観点からすれば、登録通知時に trans タグを使う必要性はありません。それを必要としてしまうと手間もかかるしどうしても抜け落ちができてしまうでしょうから… 	 
 
なるほど、翻訳文書一覧の生成と trans タグには直接関係がなく、trans タグはあくまで利用者の利便性のために用意されているということですね。僕はてっきり一覧生成に trans タグを識別しているのかなと思っていたので。
 
 
ただ、モデレータの人に登校記事中のステータスをまめにチェックしてもらって、記入ミスや記入漏れがなくなれば、trans タグを識別することで、一覧の文書ステータスまで書き換えることができるのではないかな、と妄想してみました。  
			 
		
 
	 
	
		 
	 
	
		dynamis  登録日: 2003年5月 22日 記事: 442 
			          
			
		
		
			
				
				  件名: Re: 和訳文書更新の仕方入門?      投稿時間: 2003年9月15日(月) 10:49  
				     
			 
			
				 
			 
			
				おはようございますぅ。 
 
 
  	  山口 wrote:  	 		  単に「更新」とされている場合、この掲示板では「更新が終わった」状態であることはわかりますが、これを将来和訳文書一覧に反映させるようにする場合、おそらく「更新」となるのでしょう。これは「更新済 」なのか「要更新 」なのかが一目ではわかりません。もちろん日付を比較することでわかるのですが、状態欄を一瞥してどういうステータスなのかを把握する点においては user friendly ではありません。 	 
 
 
これについては、一覧生成時にステータスに対応する文字列は好きなようにできますので問題ないと思います。データとしてはあくまで update (実装上は正規化のために単なる整数値にするかも)と記録されるだけですから、場面に応じて出力は変えます。
 
一覧ページでは finish も update も同じように "完了" とだけ通知しても良いです。
 
 
  	  山口 wrote:  	 		  そこで、こうしてみてはどうかな?と思うのです。
 
 
更新タグがなくなり、登録タグになっています。なぜか?
 
 
和訳文書の更新をする際には、原則として、改めて(更新作業のための)予約宣言をしてから作業に取り掛かります。ですから、初翻訳と同じ過程を踏むわけです。なので、その他の過程も始めて翻訳する場合と同様に、「予約 」→「草稿 」→「完了 」でことが足りると思うのです。そこで、管理者の人が「登録 」通知を出せば、流れとしてはスムーズに行くのではないではないでしょうか?  	 
 
 
うーん。
 
登録通知を出す作業自体が手間になってしまっているのではないかと思うのですが?
 
管理者が全ての文書を確認して回らずとも、必要なデータは訳が報告された時点で既に得られています。登録だけ別にすると、どうしても日付や訳者といった省略可能項目が忘れがちになると思うのです。自動保管機能が裏目になって、登録者が訳者に成り済まし状態…(笑)
 
 
  	  山口 wrote:  	 		  というわけで、上のように感じている人もいるということで(僕だけかも(笑)、ちょっと検討してみてもらえますか?
 
#いらないかも、と言ってみたり、やっぱりあってもいいかも、と言ってみたり 
 
#告白しますが、実はいままで「更新」タグをどのような場面で使っていいのか分からなかったんです。   	 
 
 
既存の一覧で初回以外は "更新" とされていたのであまり深く考えずに導入しました。
 
本当は私も "完了" までの三つで十分じゃないか?と疑問もあったのですが、現状既に和訳作業の流れの中で "更新" というものは(別途ガイドが作成されるくらい!)独立性のある作業になっていると思いますし、利用者の皆さんもあまり違和感なく利用されているみたいですのでこれでよいのではないかと思ってきています。
 
 
折角山口さんが精力的にやって下さっているところ水を差すようですが、作業の効率化という意味ではやはり "登録" という段階は無くても良いのではないでしょうか?その段階が必須になってしまうと山口さんが不在の時などに困りそうですし。
 
これはあくまでも、少なくともデータ収集の観点で不要と言うことです。念のため。訳して下さった方にお礼を述べる意味では登録の挨拶は非常に重要だと思います。いつも山口さんがそうやって下さっているお陰で JTP のモチベーションも高められていると思います。 
 
 
どうしましょうかね?
 
# 単に update -> register と既存のデータを変換する作業を嫌がってるわけではない。多分。(笑)
 
 
  	  山口 wrote:  	 		  なるほど、翻訳文書一覧の生成と trans タグには直接関係がなく、trans タグはあくまで利用者の利便性のために用意されているということですね。僕はてっきり一覧生成に trans タグを識別しているのかなと思っていたので。
 
 
ただ、モデレータの人に登校記事中のステータスをまめにチェックしてもらって、記入ミスや記入漏れがなくなれば、trans タグを識別することで、一覧の文書ステータスまで書き換えることができるのではないかな、と妄想してみました。 	 
 
 
分かりにくくてスミマセン。現在まだ未実装というだけで、一覧の生成と trans タグはリニアに関係します。和訳一覧のデータは trans タグから収集します。 trans タグ以外からは自動収集できません。
 
# それができる、し易い形式での実装を模索していた時期が"試験期間中"でした。
 
# 一覧生成などは BBCode の表示処理などとは別途行えるようにして、後回しにしたのです。
 
一方で、一覧生成と登録通知の間ではあまり関連性がありません。スタッフ側で通知している時点ではすでに trans タグでデータが得られる形(一覧の視点からすれば既に登録済)になっているので、一覧のためのデータ収集という意味では登録時に trans タグを使用すると冗長になるのです。
 
 
登録通知に BBCode を使用する場合は trans タグとは別の BBCode を用意する方が良いかも知れないというのはその為です。
 
 
 
以下、ちょっとややこしいので "ふーん、へぇー" 程度で読み流して頂ければ…(^^;
 
trans タグ使用時に即座に反映されないというのは、データ処理上の都合に過ぎません。即時反映することもできますが、ちゃんと出力できるのを確認するまでは半自動の方が良さそうだと言うことと、実装するまでに数多くの trans タグが使用されているものからデータを収集するために書くコードをそのまま利用できることになって手間が省けるからです。投稿時即時であるか私が反映作業用スクリプトを走らせるときであるかという時間的ずれがあるだけで trans タグのデータがそのまま一覧のデータとして収集されることに代わりはありません。
 
最終的には私の手間も無くすために投稿時即時データベース登録、一覧生成もデータベースから動的生成となり、trans タグの使用が即時一覧に反映される形になるハズ。これを実現する上で最大の問題は、私のやる気がそれまで保つかどうか…(笑)  
			 
		
 
	 
	
		 
	 
	
		山口  登録日: 2003年5月 23日 記事: 2920 
			           
			
		
		
			
				
				  件名: Re: 和訳文書更新の仕方入門?      投稿時間: 2003年9月15日(月) 13:14  
				     
			 
			
				 
			 
			
				こんにちは。 
 
  	  dynamis wrote:  	 		  既存の一覧で初回以外は "更新" とされていたのであまり深く考えずに導入しました。  	 
 
僕自身に限って言うと、「登録」と「更新」、「完了」はかなり適当につけてました(汗
 
 
  	  dynamis wrote:  	 		  分かりにくくてスミマセン。現在まだ未実装というだけで、一覧の生成と trans タグはリニアに関係します。和訳一覧のデータは trans タグから収集します。 trans タグ以外からは自動収集できません。
 
# それができる、し易い形式での実装を模索していた時期が"試験期間中"でした。
 
# 一覧生成などは BBCode の表示処理などとは別途行えるようにして、後回しにしたのです。
 
一方で、一覧生成と登録通知の間ではあまり関連性がありません。スタッフ側で通知している時点ではすでに trans タグでデータが得られる形(一覧の視点からすれば既に登録済)になっているので、一覧のためのデータ収集という意味では登録時に trans タグを使用すると冗長になるのです。  	 
 
なるほど、「完了」とされる時点までに、一覧生成に関して必要な情報(訳者、日付、登録予定のディレクトリ)が分かってしまうわけですね。
 
 
ただ、「完了」と登録時間に大きな差が起きて、翻訳は終了しているけれど mozilla.gr.jp サーバには登録されていない状態がありうると思うのです。これが気になるのです。一覧で「完了」となっているにもかかわらず、該当ディレクトリにファイルがない可能性もあるわけですよね?
 
 
そのため「登録」コードを用意して、「登録」投稿があったものに関して作業が完全に終わった、というようにしてはどうかな?ということです。僕の頭の中にある和訳作業手順(初訳も更新も同じ )は:
 
 
予約:作業開始!
 
 ↓
 
草稿:皆で校正!
 
 ↓
 
完了:翻訳は終了。でもまだ mozilla.gr.jp サーバに登録されていないので、作業全体から見るとまだ途中。
 
 ↓
 
登録:これで翻訳が mozilla.gr.jp サーバで公開され完了! 
 
 
という感じです。翻訳者全員が翻訳終了と同時に mozilla.gr.jp サーバに文書を登録できるわけではないので、「完了」と「登録」を区別したいわけです。
 
 
  	  dynamis wrote:  	 		  その段階が必須になってしまうと山口さんが不在の時などに困りそうですし。  	 
 
これは、現在はたまたま僕が全部こなせてしまっているだけでして、本来はスタッフ全員が分担して行う作業です。 
 
僕一人がいなくなった為にプロジェクトの作業に滞りが出るのは極力避けたいと思います。この登録を専門にやってくれるスタッフを募集してもいいです。
 
 
  	  dynamis wrote:  	 		  # 単に update -> register と既存のデータを変換する作業  	 
 
これが問題ですね。どのくらいの作業量になるのか、僕には見当がつかないのでなんともいえないですが。一番楽で簡単だと思われるのは:
 
「更新」をなくして、これまでの「更新」データを「完了」に変換する。
 
 以後は、「予約」、「草稿」、「完了」のみのコードを使用する。
 
 「登録」コードは特に設けずに、管理者ができる範囲でお知らせを出す。
 
 予約・草稿の告知作業、翻訳文書の登録作業はスタッフが分担する。
 
 (もう少しスタッフを増やす?)  
 
 
どうでしょう?ほかの人の意見も聞きたいです。  
			 
		
 
	 
	
		 
	 
	
		dynamis  登録日: 2003年5月 22日 記事: 442 
			          
			
		
		
			
				
				  件名: Re: 和訳文書更新の仕方入門?      投稿時間: 2003年9月16日(火) 02:29  
				     
			 
			
				 
			 
			
				 	  山口 wrote:  	 		  翻訳者全員が翻訳終了と同時に mozilla.gr.jp サーバに文書を登録できるわけではないので、「完了」と「登録」を区別したいわけです。 	 
 
 
なるほど確かにその通りですね。
 
和訳作業の流れとしては区別が必要なところですね。訳すことだけしか意識になかったです。(^^;
 
 
  	  山口 wrote:  	 		  これは、現在はたまたま僕が全部こなせてしまっているだけでして、本来はスタッフ全員が分担して行う作業です。:-)
 
僕一人がいなくなった為にプロジェクトの作業に滞りが出るのは極力避けたいと思います。この登録を専門にやってくれるスタッフを募集してもいいです。 	 
 
 
いやはや、耳が痛い。(^^;
 
ちょくちょく私もやらせて頂きます。
 
 
  	  山口 wrote:  	 		   	  dynamis wrote:  	 		  # 単に update -> register と既存のデータを変換する作業  	 
 
これが問題ですね。どのくらいの作業量になるのか、僕には見当がつかないのでなんともいえないですが。  	 
 
 
いや、正規表現と sed などのツールに慣れ親しんでいれば一撃です。
 
慣れてない私にはちょっと試行錯誤も必要かも知れませんが、作業自体はワンライナーで一括処理できるタイプのものですので数分いじっていればできるでしょう。(^^;
 
# そもそも自動処理できる対象として用意していますからね~
 
 
何をどうするにしても、私の手間というのは考慮しなくて良いです。大概のことは簡単に済ませられますから…
 
 
  	  山口 wrote:  	 		  一番楽で簡単だと思われるのは:
 
「更新」をなくして、これまでの「更新」データを「完了」に変換する。
 
 以後は、「予約」、「草稿」、「完了」のみのコードを使用する。
 
 「登録」コードは特に設けずに、管理者ができる範囲でお知らせを出す。
 
 予約・草稿の告知作業、翻訳文書の登録作業はスタッフが分担する。
 
 (もう少しスタッフを増やす?)  
 
 
どうでしょう?ほかの人の意見も聞きたいです。 	 
 
 
入力の手間やミスを考慮するとそんな感じで宜しいかと。何かの際に完了と更新を区別が必要になったとしても、今後は二度目以降の完了が更新だと見なすことで再現できますし。
 
数日様子を見て他に意見等無ければ適当なときに "更新" コードの併合をしておきます。  
			 
		
 
	 
	
		 
	 
	
		dynamis  登録日: 2003年5月 22日 記事: 442 
			          
			
		
		
			
				
				  件名: Re: 和訳文書更新の仕方入門?      投稿時間: 2003年10月05日(日) 08:20  
				     
			 
			
				 
			 
			
				 	  dynamis wrote:  	 		  数日様子を見て他に意見等無ければ適当なときに "更新" コードの併合をしておきます。 	 
 
 
先週末あたりには処理する予定だったのですがちょっと忙しくって後回しにしてしまっていました。
 
何にしても既存の trans タグのうち update は全て finish に置き換えました。
 
入力テンプレートからも"更新"は除去しましたので、今後は更新時も"完了"を使用して報告してください。  
			 
		
 
	 
	
		 
	 
	
		山口  登録日: 2003年5月 23日 記事: 2920 
			           
			
		
		
			
				
				  件名: Re: 和訳文書更新の仕方入門?      投稿時間: 2003年10月05日(日) 09:31  
				     
			 
			
				 
			 
			
				 	  dynamis wrote:  	 		  何にしても既存の trans タグのうち update は全て finish に置き換えました。
 
入力テンプレートからも"更新"は除去しましたので、今後は更新時も"完了"を使用して報告してください。 	 
 
 
どうもありがとうございます。大きな変更ではないので、特に混乱はないでしょう。