先谢谢这个库——我们在生产里用它做六十甲子与八字计算，很稳。下面三条都出在 en 语言包，按「确定性」从高到低排，互相独立，可分开处理。我愿意按你认可的方案提 PR。
环境：lunar-typescript@1.8.6（npm）· Node v24.18.0
1. ny.jianXia 拼写错误
I18n.setLanguage('en');
I18n.getMessage('ny.jianXia'); // → 'Valleyn'应为 Valley（涧下）。一个字符。
2. 英文里复合字符串没有分隔符
LunarUtil.NAYIN 的值是 {ny.x}{wx.y} 模板。中文拼接正确（海中+金 = 海中金），英文直接拼就粘在一起了：
const { I18n, Solar } = require('lunar-typescript');
I18n.setLanguage('en');
const e = Solar.fromYmdHms(1990, 7, 15, 10, 0, 0).getLunar().getEightChar();
console.log(e.getYearNaYin(), e.getMonthNaYin(), e.getDayNaYin(), e.getTimeNaYin());
// RoadsideEarth WillowWood WaxMetal FlowsWater
console.log(e.getDayWuXing());
// MetalFire30 个纳音全部受影响，getYearWuXing() / getDayWuXing() 同样。
分隔符不能全局加：getYearXun() → JiaYin、getDayXunKong() → ShenYou 这类干支拼接，不加空格才是对的。所以要么按模板类别决定，要么给语言包一个分隔符键。两种改法我都能写，看你倾向哪种设计——这块是你的架构，我不擅自改。
（附带一提，ny.changLiu: 'Flows'（长流）加了空格也还是 Flows Water，语法上不成立；这条属于用词而非分隔符，见文末。）
3. en 缺 299 个键，缺失时静默回落中文
getMessage() 在 en 查不到时回落 _DEFAULT_LANG（chs），所以英文调用方会拿到中英混排的结果：
e.getDayDiShi(); // → '死'
e.getDayShiShenGan(); // → '日主'
对 1.8.6 的 I18n.ts 做键集对比，chs 799 键 / en 500 键，缺 299：
| 前缀 |
缺失数 |
是什么 |
sn |
137 |
神煞 |
h |
75 |
|
d |
30 |
|
m |
12 |
|
ds |
12 |
十二长生（长生/沐浴/冠带…） |
ss |
10 |
十神（比肩/劫财/食神…） |
dw |
7 |
|
yx |
7 |
月相 |
| 其余 |
9 |
od ps s jr |
sn 那 137 条工作量大、译法也有争议，我不碰。但 ds(12) 与 ss(10) 这 22 条是八字英文输出的必经之路——getDayDiShi()、getShiShenGan() 这些 API 现在对英文用户是不可用的。这 22 条我可以提 PR。
另一个选择是让缺键回落到 key 本身或抛错，至少不静默混排——但那是 breaking change，得你定。
顺带说明两件事，避免误会：
- 我看了
tyme4ts，它没有 i18n 层，所以英文这条路目前只有 lunar-typescript。这也是我把问题提在这里而不是那边的原因。
- 第 2 条末尾提到的用词问题（
Flows、Coniferin、Valleyn）：我们自己维护了一份三十纳音的英译表，CC BY 4.0，可以随便用，无需任何回报：https://github.com/Shann5/bazi-nayin。但这跟前三条是两回事——译法是审美判断，你完全可以不采纳；上面的拼写、分隔符、缺键是客观缺陷。要是你只想修那三条，我照样乐意提 PR。
需要我从哪条开始？
先谢谢这个库——我们在生产里用它做六十甲子与八字计算，很稳。下面三条都出在
en语言包，按「确定性」从高到低排，互相独立，可分开处理。我愿意按你认可的方案提 PR。环境：
lunar-typescript@1.8.6（npm）· Node v24.18.01.
ny.jianXia拼写错误应为
Valley（涧下）。一个字符。2. 英文里复合字符串没有分隔符
LunarUtil.NAYIN的值是{ny.x}{wx.y}模板。中文拼接正确（海中+金 = 海中金），英文直接拼就粘在一起了：30 个纳音全部受影响，
getYearWuXing()/getDayWuXing()同样。分隔符不能全局加：
getYearXun()→JiaYin、getDayXunKong()→ShenYou这类干支拼接，不加空格才是对的。所以要么按模板类别决定，要么给语言包一个分隔符键。两种改法我都能写，看你倾向哪种设计——这块是你的架构，我不擅自改。（附带一提，
ny.changLiu: 'Flows'（长流）加了空格也还是Flows Water，语法上不成立；这条属于用词而非分隔符，见文末。）3.
en缺 299 个键，缺失时静默回落中文getMessage()在en查不到时回落_DEFAULT_LANG（chs），所以英文调用方会拿到中英混排的结果：对 1.8.6 的
I18n.ts做键集对比，chs799 键 /en500 键，缺 299：snhdmdsssdwyxodpssjrsn那 137 条工作量大、译法也有争议，我不碰。但ds(12) 与ss(10) 这 22 条是八字英文输出的必经之路——getDayDiShi()、getShiShenGan()这些 API 现在对英文用户是不可用的。这 22 条我可以提 PR。另一个选择是让缺键回落到 key 本身或抛错，至少不静默混排——但那是 breaking change，得你定。
顺带说明两件事，避免误会：
tyme4ts，它没有 i18n 层，所以英文这条路目前只有lunar-typescript。这也是我把问题提在这里而不是那边的原因。Flows、Coniferin、Valleyn）：我们自己维护了一份三十纳音的英译表，CC BY 4.0，可以随便用，无需任何回报：https://github.com/Shann5/bazi-nayin。但这跟前三条是两回事——译法是审美判断，你完全可以不采纳；上面的拼写、分隔符、缺键是客观缺陷。要是你只想修那三条，我照样乐意提 PR。需要我从哪条开始？