我们如何将资源文件与任何翻译管理工具集成
我正在在ASP.NET MVC中开发的多语言站点。当前，我们使用资源（RESX）文件管理翻译任务，一切正常。 现在，根据客户端的要求，他们希望通过Webhook将我们的资源文件集成到TMS“短语”。因此，将来，如果他们创建任何新密钥或修改现有资源文件。它自动反映在应用程序RESX文件中，并应自动反映DEV/TEST/POD环境。
当我尝试更新API呼叫上的资源文件时，它进行了修改并在应用程序上反映了更改。
但是，当我们在app_globalresources文件夹下修改RESX文件时，它将重新启动整个应用程序。因此，这是使用此方法的缺点之一。同样，当我们部署更改时，它就可以使App_globalreources的dll。部署后，无法添加新的或对现有翻译进行更改。
任何人都可以提出一种最佳方法，我们应该考虑实现上述要求。
编辑： - 我们可以在现有应用程序中使用JSON代替RESX文件吗？
I am working on multilingual site developed in asp.net MVC. Currently we are managing the translation task using resource (resx) file and everything is working fine.
Now as per client requirement, they want to integrate our resource file to a TMS "phrase" through a webhook. So in future, if they create any new key or modifying the existing resource file. Its automatically reflects in application resx file and it should automatically reflects on dev/test/prod environment.
As I tried to update the resource file on API call, its get modified and changes are reflected on application.
But when we modified the resx file under app_GlobalResources folder then it restarts the whole application. so this is one of drawback to use this approach. Also when we deploy our changes then it makes the dll of app_globalreources. Post deployment, unable to add new or make changes in existing translation.
Can any one suggest a best approach, which we should consider to fulfill above requirement.
Edit:-
Can we use json instead of resx file in existing application.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
进行翻译的一种常见方法是通过数据库改为资源文件。您将相同的信息保存在数据库中：语言，键（资源名称）和值（翻译的文本）。
有了这个重点，您必须开发一种进行翻译（典型的CRUD操作）和某些层以获取每种语言的任何键的方法。
与您的客户交谈并检查此功能的重要性。不久前，我从事这样的项目工作，最后，我们从来没有以这种方式进行翻译。我们添加了更多功能，进行了更改，翻译，并且在迭代完成后，我们将进入生产所有内容。也许不是您的情况，但这是可惜的工作，而后来却没有使用。
A common way to do translations is through database instead resource files. You save the same information in your database: language, key (the resource name) and value (the translated text).
With this focus, you must develop a way to do translations (the typical CRUD operations) and some layer to get any key in each language.
Talk with your client and check how important is this feature. I worked in a project like this some time ago and, at the end, we never do translations in this way. We add more functionality, made changes, translations and, when iteration finished, we move to production everything. Maybe not your case but it's a pity work on something that later hasn't use.