回答編集履歴
1
コメントへの反応追記
test
CHANGED
|
@@ -51,3 +51,68 @@
|
|
|
51
51
|
constやletが無くて単に再宣言で上書きされているだけであれば、ぶっちゃけそれはそれで問題ない（問題はあるけど絶対に避けられない理由があるなら仕方がない）ような気もしますが
|
|
52
52
|
言語切り替え時に既存の内容を全削除しなければいけないような仕組みなのでしょうか？
|
|
53
53
|
|
|
54
|
+
----
|
|
55
|
+
# ※2024/04/12 13:00 追記
|
|
56
|
+
|
|
57
|
+
リポジトリ確認しました。
|
|
58
|
+
|
|
59
|
+
まず1つ私が書いた部分の訂正ですが
|
|
60
|
+
「関数や変数がグローバルに全展開される仕組み」ではなく
|
|
61
|
+
`Blockly.Blocks.xxxx.init` に各ブロックの情報を登録する、のようです。
|
|
62
|
+
つまり、各言語scriptを読み込みした結果、`Blockly.Blocks`オブジェクトのプロパティに(上書き)登録する処理が実行される、ということです。
|
|
63
|
+
ですので、複数回実行しても特に問題はありません（単に最後に実行した方の言語が使用される）。
|
|
64
|
+
|
|
65
|
+
「関数や変数がグローバルに全展開される仕組み」も4割ぐらい正解で「関数や変数がBlockly専用グローバルオブジェクト配下に展開される仕組み」みたいな感じでした。
|
|
66
|
+
|
|
67
|
+
|
|
68
|
+
|
|
69
|
+
以下、コメントに反応します。
|
|
70
|
+
|
|
71
|
+
## 言語script
|
|
72
|
+
>ブロックタイプとブロック情報をもつファイルが1対1でないとブロックが表示されなくなってしまうので入れていた
|
|
73
|
+
そもそもの話、現状は **「各言語scriptの読み込みが完了しないままrestoreBlocksとかを試みているので失敗してる」** ように見えます。
|
|
74
|
+
特に1対1とか必要はなく、各ブロックタイプに対して言語を問わず漏れなく1回以上読み込んでいればokです。
|
|
75
|
+
|
|
76
|
+
おそらく何か試行錯誤の過程でそのような勘違いに至ったのだと予想できるのですが
|
|
77
|
+
「既存の内容を削除」について、少なくとも今回は特に意味がなく発生している問題と関係ないということは認識しておいてください。（例えばscriptタグが意味もなく何千何万と増えたらDOMが肥大化するとかはあるかもしれないので、そういう観点では意味がないことはないかもしれません）
|
|
78
|
+
|
|
79
|
+
|
|
80
|
+
## 処理順・実装方法について
|
|
81
|
+
|
|
82
|
+
1. 現状
|
|
83
|
+
1. ブロックを置く
|
|
84
|
+
2. リロード
|
|
85
|
+
3. POP UPで言語を選択
|
|
86
|
+
4. 選択言語に従ったブロック情報を持つファイルを読み込み
|
|
87
|
+
2. 本来必要な処理順序 ※script.jsに記述する順序とは限らない
|
|
88
|
+
1. 各言語scriptの読み込み(選択言語に従ったブロック情報を持つファイルを読み込み)
|
|
89
|
+
2. 画面の構築 (初期化または以前の記録をrestoreBlocks)
|
|
90
|
+
3. ユーザ操作 (言語設定切り替えもこのタイミングで、画面リロードを挟めば難しいことをせずに別言語にして1.からやり直せる)
|
|
91
|
+
|
|
92
|
+
上記1.の各言語scriptの読み込みですが、何らかの手法でサーバ側で切り替え(静的htmlファイルを切り替えるまたはhtmlを動的に組み立てるまたは各言語scriptの方を切り替えるetc)して、html内にscript要素が記述されているのを普通に読み込むのなら簡単なのですが
|
|
93
|
+
現状のsetLanguage関数のようにクライアント側のスクリプト内で動的ロードしようとすると割と複雑で面倒だと思います。（動的に読み込んだscriptファイルが全て読み込み完了したのを明示的に待ち受ける必要がある）
|
|
94
|
+
少なくとも現状のままsetLanguage→restoreBlocksの順で実行してもたぶんだめです（開発環境だとサーバが近いのでレスポンスが早く、たまたま成功してしまって真の問題の露見が遅れる可能性）
|
|
95
|
+
|
|
96
|
+
|
|
97
|
+
|
|
98
|
+
## 方針
|
|
99
|
+
>本質問のコメント欄にあるCookieによる実装もこの手法
|
|
100
|
+
cookieは特にどの方針かを制限しません。
|
|
101
|
+
①の「URLの階層やクエリパラメータにjaとかenを含んでおいてサーバ側処理で切り替える実装」の「URLの階層やクエリパラメータ」の部分を「http requestのheaderに含まれるcookie内」に置き換えただけ、というサーバ側切り替えの方針にもできますし
|
|
102
|
+
②～④のどれを選んでも特に問題はありません。
|
|
103
|
+
|
|
104
|
+
特に上記のマトリックス表で明示してはいませんでしたが、②～④を選ぶにしても
|
|
105
|
+
cookieを使うのならサーバ側切り替えにしてもよいですし、クライアント側切り替えにしてもよいです。(クライアント側のみでやるならlocalStorageと似たような扱いになります)
|
|
106
|
+
|
|
107
|
+
|
|
108
|
+
|
|
109
|
+
|
|
110
|
+
## >追記
|
|
111
|
+
> とすればリロードのボタンを押す必要はないのですね
|
|
112
|
+
それは固定テキストをcssで切り替えるやり方なので、今回の言語scriptの話とは別です。
|
|
113
|
+
固定テキストも複数言語対応したい、というのであれば、別途導入すると良いと思います。
|
|
114
|
+
|
|
115
|
+
UIの種類としての話なら、言語選択の仕方は何でも良いです。
|
|
116
|
+
ページ内に言語の数だけボタンを並べてもよいですし、設定ダイアログやポップアップでも良いです。
|
|
117
|
+
とにかくユーザ操作に対して言語設定を指定または保持→ページリロードなどの更新処理、という一連の処理がかければよいです。
|
|
118
|
+
（もしも『リロードのボタン』というのがブラウザの更新ボタンを意味しているのであれば、ここでは特に関係はありません）
|