feat: Google IMEと同等の日付変換フォーマットを追加 by him0 · Pull Request #276 · azooKey/azooKey-Desktop

him0 · 2026-01-12T15:13:19Z

Summary

「きょう」「きのう」「あした」などの日付変換で、Google IMEと同等のフォーマットを追加
ハイフン区切り（2026-01-12）
ゼロ埋めなし漢字表記（2026年1月12日）
和暦表記（令和8年1月12日）
曜日のみ（月曜日）

変更内容

日付変換フォーマットの追加（522f762）
フィードバック対応: ゼロ埋めあり漢字表記（2026年01月12日）を廃止し、ゼロ埋めなし（2026年1月12日）のみを採用（795425c）
実装のリファクタリング: 3つのflatMapブロックを1つに統合、CalendarTypeを配列として明示的に指定（f5e1709）
優先度（value）の値を連番に整理（cd1e3ee）
コードフォーマットの調整（94ec11e）

Test plan

アプリをビルドして起動
「きょう」と入力し、新しいフォーマットが変換候補に表示されることを確認

🤖 Generated with Claude Code

「きょう」「きのう」「あした」などの日付変換に以下のフォーマットを追加: - ハイフン区切り（2026-01-12） - ゼロ埋めなし漢字表記（2026年1月12日） - 和暦表記（令和8年1月12日） - 曜日のみ（月曜日） Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

ensan-hcl · 2026-01-12T15:20:37Z

ほかのIMEとのfeature alignmentの観点だと、0埋め有りと無しを両方入れるのではなく、単に0埋めなしにするのが良いかもしれません。

him0 · 2026-01-12T15:22:41Z

早速の反応ありがとうございます。対応します！

他のIMEとのfeature alignmentを考慮し、ゼロ埋めあり（2026年01月12日）を削除してゼロ埋めなし（2026年1月12日）のみを採用 Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

ensan-hcl · 2026-01-12T15:40:45Z

Core/Sources/Core/InputUtils/SegmentsManager.swift

+            + [("Gyyyy年M月d日", -18.4)].flatMap { (format, value: PValue) in
+                [
+                    .init(word: DateTemplateLiteral(format: format, type: .japanese, language: .japanese, delta: "-2", deltaUnit: 60 * 60 * 24).export(), ruby: "オトトイ", cid: CIDData.固有名詞.cid, mid: MIDData.一般.mid, value: value),
+                    .init(word: DateTemplateLiteral(format: format, type: .japanese, language: .japanese, delta: "-1", deltaUnit: 60 * 60 * 24).export(), ruby: "キノウ", cid: CIDData.固有名詞.cid, mid: MIDData.一般.mid, value: value),
+                    .init(word: DateTemplateLiteral(format: format, type: .japanese, language: .japanese, delta: "0", deltaUnit: 1).export(), ruby: "キョウ", cid: CIDData.固有名詞.cid, mid: MIDData.一般.mid, value: value),
+                    .init(word: DateTemplateLiteral(format: format, type: .japanese, language: .japanese, delta: "1", deltaUnit: 60 * 60 * 24).export(), ruby: "アシタ", cid: CIDData.固有名詞.cid, mid: MIDData.一般.mid, value: value),
+                    .init(word: DateTemplateLiteral(format: format, type: .japanese, language: .japanese, delta: "2", deltaUnit: 60 * 60 * 24).export(), ruby: "アサッテ", cid: CIDData.固有名詞.cid, mid: MIDData.一般.mid, value: value)
+                ]


パッと見でなぜ上のflatMapのところに足せないのかわからなかったのですが、どういう意図でしょうか？

もともとが令和の表記を含んだ候補がなくて、令和の表記を出すためには
DateTemplateLiteral で type: .japanese を指定する必要があるので分割しています

なるほど、理解です！そしたら、CalendarType（でしたっけ）を元のflatMapしてるarray側で明示的に指定する実装にしたいです。繰り返しを避けたいためです。

ensan-hcl · 2026-01-12T15:40:58Z

Core/Sources/Core/InputUtils/SegmentsManager.swift

+            + [("E曜日", -18.5)].flatMap { (format, value: PValue) in
+                [
+                    .init(word: DateTemplateLiteral(format: format, type: .western, language: .japanese, delta: "-2", deltaUnit: 60 * 60 * 24).export(), ruby: "オトトイ", cid: CIDData.固有名詞.cid, mid: MIDData.一般.mid, value: value),
+                    .init(word: DateTemplateLiteral(format: format, type: .western, language: .japanese, delta: "-1", deltaUnit: 60 * 60 * 24).export(), ruby: "キノウ", cid: CIDData.固有名詞.cid, mid: MIDData.一般.mid, value: value),
+                    .init(word: DateTemplateLiteral(format: format, type: .western, language: .japanese, delta: "0", deltaUnit: 1).export(), ruby: "キョウ", cid: CIDData.固有名詞.cid, mid: MIDData.一般.mid, value: value),
+                    .init(word: DateTemplateLiteral(format: format, type: .western, language: .japanese, delta: "1", deltaUnit: 60 * 60 * 24).export(), ruby: "アシタ", cid: CIDData.固有名詞.cid, mid: MIDData.一般.mid, value: value),
+                    .init(word: DateTemplateLiteral(format: format, type: .western, language: .japanese, delta: "2", deltaUnit: 60 * 60 * 24).export(), ruby: "アサッテ", cid: CIDData.固有名詞.cid, mid: MIDData.一般.mid, value: value)
+                ]
+            }


同じくで、パッと見でなぜ上のflatMapのところに足せないのかわからなかったのですが、どういう意図でしょうか？

これはまとめる選択肢も問題なく取れると思いました

まとめたいです！

ensan-hcl · 2026-01-12T15:41:38Z

MM/ddとMM月dd日（E）など、他のMM系も他のIMEに寄せたいです

him0 · 2026-01-12T16:11:09Z

@ensan-hcl

現在対応しているフォーマットは以下で

MM/dd → 01/13
yyyy/MM/dd → 2026/01/13
yyyy-MM-dd → 2026-01-13
MM月dd日（E） → 01月13日（月）
yyyy年M月d日 → 2026年1月13日
Gyyyy年M月d日 → 令和8年1月13日
E曜日 → 月曜日

MM月dd日（E）のパターンのみが日本語を含みつつ、0埋めになっているので、0埋めをやめたほうが良いように思いました
MM/dd に関しては、yyyy/MM/dd が 0埋めしているので、そのままにしたほうがいいかなと思ってのですが、意見伺いたいです

また画像を貼っていただいた変換パーンの中で、R08/01/13 のパターンに関してこちらは追加対応したほうがいいか教えてほしいです

ensan-hcl · 2026-01-12T16:14:46Z

MM/dd → 01/13
MM/dd に関しては、yyyy/MM/dd が 0埋めしているので、そのままにしたほうがいいかなと思ってのですが、意見伺いたいです

これはmacOS標準の日本語入力（1枚目）がMM/ddではなくM/ddになってるので合わせようという意図です！
MM月dd日（E）をM月…にするのは同意です。

R08/01/13は使う人いるのかよくわからないので要望来てからでいいかなと思いました。

- 3つのflatMapブロックを1つに統合 - CalendarTypeを配列の要素として明示的に指定 - MM/dd → M/d、MM月dd日（E） → M月d日（E）（ゼロ埋めなし） Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

him0 · 2026-01-12T16:40:08Z

build 通るんですけど、ローカル反映ができずの状態で、PR Open にしちゃいました、すみません
自分の環境で動作確認を引き続き試してみますが @ensan-hcl さんの方で大丈夫そうであれば取り込んでもらえると助かります

ensan-hcl · 2026-01-13T13:38:37Z

Core/Sources/Core/InputUtils/SegmentsManager.swift

+            [
+                ("M/d", -18, DateTemplateLiteral.CalendarType.western),
+                ("yyyy/MM/dd", -18.1, .western),
+                ("yyyy-MM-dd", -18.15, .western),


ここを-18.15にする意味は特になさそうなので-18.1, -18.2, ... -18.6にしませんか？

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

ensan-hcl · 2026-01-13T15:26:30Z

Core/Sources/Core/InputUtils/SegmentsManager.swift

+            }
+            + [


ここの差分は多分不要なので戻してください！ 🙏

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

ensan-hcl

LGTMです！

ensan-hcl reviewed Jan 12, 2026

View reviewed changes

him0 marked this pull request as draft January 12, 2026 15:42

him0 marked this pull request as ready for review January 12, 2026 16:20

ensan-hcl reviewed Jan 13, 2026

View reviewed changes

refactor: 日付変換フォーマットの優先度を連番に整理

cd1e3ee

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

ensan-hcl reviewed Jan 13, 2026

View reviewed changes

style: 配列結合演算子のフォーマットを調整

94ec11e

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

ensan-hcl assigned him0 Jan 14, 2026

ensan-hcl added the enhancement New feature or request label Jan 14, 2026

ensan-hcl self-requested a review January 14, 2026 15:33

ensan-hcl approved these changes Jan 14, 2026

View reviewed changes

ensan-hcl merged commit db22f23 into azooKey:main Jan 14, 2026
4 checks passed

patt812 mentioned this pull request Mar 4, 2026

feat: 「いま」の変換で現在時刻の入力に対応 #298

Merged

4 tasks

Uh oh!

Conversation

him0 commented Jan 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

変更内容

Test plan

Uh oh!

ensan-hcl commented Jan 12, 2026

Uh oh!

him0 commented Jan 12, 2026

Uh oh!

ensan-hcl Jan 12, 2026

Choose a reason for hiding this comment

Uh oh!

him0 Jan 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ensan-hcl Jan 12, 2026

Choose a reason for hiding this comment

Uh oh!

ensan-hcl Jan 12, 2026

Choose a reason for hiding this comment

Uh oh!

him0 Jan 12, 2026

Choose a reason for hiding this comment

Uh oh!

ensan-hcl Jan 12, 2026

Choose a reason for hiding this comment

Uh oh!

ensan-hcl commented Jan 12, 2026

Uh oh!

him0 commented Jan 12, 2026

Uh oh!

ensan-hcl commented Jan 12, 2026

Uh oh!

him0 commented Jan 12, 2026

Uh oh!

ensan-hcl Jan 13, 2026

Choose a reason for hiding this comment

Uh oh!

ensan-hcl Jan 13, 2026

Choose a reason for hiding this comment

Uh oh!

ensan-hcl left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

him0 commented Jan 12, 2026 •

edited

Loading

him0 Jan 12, 2026 •

edited

Loading