create_kanaを疑問文に対応してaudio_query時に？が母音に書き換わってしまうのを抑止するようにした#255
create_kanaを疑問文に対応してaudio_query時に？が母音に書き換わってしまうのを抑止するようにした#255qwerty2501 wants to merge 2 commits intoVOICEVOX:masterfrom
Conversation
Pull Request Test Coverage Report for Build 1646114330
💛 - Coveralls |
Coverage ResultResultを開く
|
qwerty2501
changed the title
voicevox_engine/kana_parser.py
Outdated
|
|
||
| def create_kana(accent_phrases: List[AccentPhrase]) -> str: | ||
| def create_kana( | ||
| accent_phrases: List[AccentPhrase], base_text: str, enable_interrogative: bool |
There was a problem hiding this comment.
たしかにここは疑問文判定をしたいだけなはずなので、base_textを渡すのは余分なデータが多いような印象を受けました。
疑問判定をAPIかこっちのどちらに持たせるかは、おそらくどっちも本当はイマイチで、エンジン内部処理用AccentPhraseを作成して変換するのが最も良いんじゃないかと感じました。
以前仰られていたレイヤードアーキテクチャにおける、データ変換？が今こそ使い時なのかなと思いました。
There was a problem hiding this comment.
data model分離がrevertされましたのでこの問題をどうするのか決めなくてはなりません。
どうしましょうかね
There was a problem hiding this comment.
やっぱりconvertは便利だと思うので、data model分離でエラーになってしまった部分を直すのがまあ筋かなと感じました。
（時間取らせちゃって申し訳ないです･･･）
直し方ですが、Model.to_engineが無理なので、staticメソッドしかないConverterクラスを作ってConverter.model_to_engineを作るか、以前のようにglobal関数としてconvert_model_to_engineを作るなどの方法を思いつきました。
名前は議論の余地ありだと感じています。
個人的にはConverterにまとめたほうがimportする手間が1回になるので良いのかなと思いました！
There was a problem hiding this comment.
そのあたりこの前converter関数実装する時に調べたのですが、pythonではこういったstatic関数のみの場合はclassに持たせるよりもmodule内にglobal関数として定義したほうがよいと書いてありました。
書き口としてはmoduleに定義した場合でもimportを関数ではなくmoduleにすればほぼ同じになるかと思います。
どっちにしますか？
There was a problem hiding this comment.
たしかに･･･
moduleにすると例えば設定値を持たせづらいかもなのでシングルトンクラスとかのが良いかもですが、将来設定値ができたときに変更で良い気がしました。
どういう書き心地になるかちょっと知りたいというのもあるので、今回はmoduleに定義で書いてみる感じを試してみる感じで・・・！
qwerty2501
force-pushed
the
feature/improve_create_kana
branch
from
dba1b13 to
40c2312
Compare
Fixeddata model分離できたので修正しました。 |
|
#264 でdata model分離がrevertされたのでdraftにします |
/accent_phrases時にis_kanaがtrueだとInternal Server errorが発生するようになったため、 VOICEVOX#255 での修正をこっちに統合した refs VOICEVOX#253,VOICEVOX#255
* 疑問文の仕様変更反映 #272 - AccentPhraseにis_interrogativeをもたせる - 疑問符Mora追加を調整前ではなく調整後に行うようにした #272 (comment) refs #272 * create_kanaを疑問文に対応 #253 /accent_phrases時にis_kanaがtrueだとInternal Server errorが発生するようになったため、 #255 での修正をこっちに統合した refs #253,#255 * printが入っていたので消した * 末尾がptich0でcreate_kanaすると？がつけられてしまうので修正 #273 (comment)
3 participants
内容
かなり場当たり的な修正になった
accent_phrasesだけでは疑問文かどうか判定できないので元になったtextとenable_interrogativeを受け取らなければならずこのような形に・・・
関連 Issue
refs #253