我正在为自己创建一个客户端-服务器应用程序，我面前出现了一个问题：“但是从架构的角度来看，实现 jsons 的部分翻译如何‘正确’”。
服务端是java+spring写的，客户端是c#+prism(unity)+refit。
Country 实体的当前代码示例。
在服务器上，代码非常简单：Controller -> Service -> Repository。
在客户端上更有趣一点：
ICountryRepository.cs
public interface ICountryRepository
{
[Get("/countries/")]
Task<IReadOnlyCollection<Country>> FindAll();
}
我查看了 UnitOfWork 模式并实际实现了它（好吧，或者我将所有存储库合并为一个），但没有保存所有更改。
存储库服务.cs
public class RepositoryService : IRepositoryService
{
public ICountryRepository Country { get; }
public RepositoryService(IAuthenticationService authenticationService)
{
Country = RestService.For<ICountryRepository>(authenticationService.HttpClient);
}
}
好吧，通过 DI，我获得了这项服务并访问了实体及其方法。在这个阶段，一切都很好。如何实现至少将国家、国籍等的字典实体（字典表）翻译到这个系统中
到目前为止，我想到了 3 个想法：
- 将所有词典的翻译存储在服务器上，使用api拉取我需要的翻译，
- 在客户端，实现 TranslateService，它将接受原始实体的集合，并在输出中返回已翻译的实体，
- 不要为每个存储库创建 RepositoryService，而是创建自己唯一的存储库，其中已经进行了翻译。
虽然我在考虑 1 和 3，但我认为 2 有点不好）也许你有什么想法，但我的方法是完全错误的。
升级版：
很多大公司都不在乎这么一个小细节（同样的steam，没有翻译国家名单的地方），但我还是想）
更新 2
对于一般的查找表，我做了以下操作：在发送数据之前，任何方法都引用从当前会话返回用户设置的组件。在其中，该方法找到当前语言，并根据它发送俄语或英语的集合。
如果您正在尝试构建类似 REST 的 API，那么本地化就是其中的一部分，这
Content-Negotiation意味着 HTTP 已经具备实现“内容协商”的方法（一种在有多种表示形式时为响应选择最佳表示形式的机制）。在我看来，最优雅的方式是使用
Accept-Language请求标头。许多 HTTP 客户端会自动传递它，例如，如果您从浏览器调用 API，则此标头将包含浏览器的区域设置。此类查询应返回俄罗斯语言环境中的国家/地区列表。
传递给 API 的第二种方式是通过查询参数：
查询应该类似地返回俄罗斯语言环境中的国家列表。
也就是说，您的服务器应用程序解析请求，从那里接收标头
Accept-Language或查询参数lang并返回所需语言环境中的列表，如果没有值，则在默认语言环境中返回给定的值。在客户端上实施本地化会带来许多不便。主要是无法快速添加、删除和编辑本地化数据。例如，如果您添加了新的国家/地区，那么您将需要向客户端添加新的语言环境，构建它并在用户之间分发，而不是在服务器上添加一次，在大多数情况下，甚至不需要被阻止。