我目前对国际化问题有所了解。我面对的是数据库设计，我不喜欢。目前，通过为每种语言添加新条目并且这些条目之间没有关系来完成国际化。
就像：
Product:10 -> English, "My Little Red Tractor"
Product:11 -> German, "Mein kleiner roter Traktor"
我不喜欢它，我想改变它：
Product:10 -> Name = languageString 101
LanguageString:101, ENGLISH -> "My Little Red Tractor"
LanguageString:101, GERMAN -> "Mein kleiner roter Traktor"
该网站规模中等，全球约有1M个游客，每天的页面展示次数约为15M（访问者每天都会多次查看该页面。这是一个社交网站。
以下是我目前的计划：
我想为语言字符串创建用户类型。语言字符串将被隐藏（仅对休眠可见）并使用自定义注释来添加瞬态字段并可公开访问。如果类中只有一个语言属性，则使用单个字符串来表示它。如果有多个属性，则将使用JSON表示。
由于我可能想要输入这个，我可能会在LanguageString中添加一个属性类型。此类型指的是此语言字符串是描述产品还是类别或其他内容。有了这种类型，我甚至可以重用产品/类别/等的id作为languageId的id。
因此SQL表中的LanguageString实体如下所示：
LanguageString(id, type, String content / jsonContent)
最后，我可以将每种语言依赖信息分解出来，并将其存储在语言依赖的LanguageString数据库条目中。由于我使用一种类型来识别每个实体领域（例如LanguageString.Types.PRODUCT = 1，... Types.CATEGORY = 2等等。甚至根据实体类添加映射），我可以使用实体的id作为语言字符串的id并执行1：1'逻辑'映射。
我知道在这样的解决方案中使用like进行排序和查询是不可能的。但我知道这一点，使用嵌入式/专用Solr或Hibernate搜索解决方案（意为Lucene）听起来很合理。
我现在缺少的是风险感和实践经验。我想根据它描述的语言字符串/实体的类型添加缓存。类别的名称不太可能改变，产品的名称不是那么多。描述更可能但不是那么多，可用的位置，语言和域的名称根本不会发生变化。但是因为它们可能会改变，所以我将使用每个实体实例的@Version属性来确定缓存的值是否仍然有效。
如果已经有这样的解决方案（开源）我会很高兴自己不必实现它（即使我认为它只需要几天）。如果您有其他实施方案，我会很高兴听到它。我很困惑，我知道这对我来说是实验性的。我将添加大量的单元测试来测试这个想法，并确保它在我继续使用这种方式实现之前完美运行。
所以请提供您的意见或替代方案。我不太确定这是实现它的方法。