Web 服务以客户端语言响应 - 如何?

发布于 2024-12-06 05:07:35 字数 431 浏览 0 评论 0原文

我正在使用 Metro 在 Java 中开发 SOAP Web 服务。 我想以客户语言提供回复。 我的想法是返回所有翻译的字符串字段。这不是 Web 服务的主要目的,而是一种必要的便利。

ResourceBundle 是一个 java 类,它处理根据客户端位置加载正确的字符串集。 这个班级是最好的接近者吗?

真正的问题是:在 WS 环境中如何知道客户端位置?

编辑: 我喜欢@Volker 的想法,让我们决定使用什么语言。

如何将意图发送给服务?

  • 标头参数?
  • 方法(体)参数?
  • 还有其他选择吗?

I am developing a SOAP web service in Java using metro.
I want to deliver the response in in the client language.
My idea is to return all the string fields translates. This is not the main purpose for the web service, but is a needed convenience.

The ResourceBundle is a java class that handles the loading of the correct set of strings according the client Location.
Is this class the best approacher?

And the real question: in a WS environment how to know the client location?

EDIT:
I like @Volker idea, let decide what language will be used.

How to send the intentions to the service?

  • Header parameter?
  • Method (body) parameter?
  • Any other option?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

口干舌燥 2024-12-13 05:07:35

一般来说,我会说,如果可能的话,让客户明确告诉你他想要什么语言,并根据他的需求交付。

这可能是一个附加的 Web 方法“getSupportedLanguages”,它提供 enUS、deDE 或其他内容的列表,并且您的其他方法可能接受这些语言并提供正确的响应。或者交付所有语言版本并让客户整理。但这可能有点网络过度杀伤力,具体取决于支持的语言环境的数量...

在我看来,Web 服务应该“独立”,客户端应该很薄,不需要大量信息来处理内容。想象一下一个 C# 客户端,他可能无法使用您的资源或其他内容。或者没有资源的新客户无法使用您的数据...

此外,真正获得客户区域设置可能会有所不同 - 非英语人员可能使用英语系统或可能位于英语国家,但会喜欢用他的母语查看数据。但如果你真的需要这样做,我不知道有什么可以实现这一点。

Generally, I would say, if possible, let the client explicitly tell you what language he wants and deliver it according to his needs.

This may be an additional web method "getSupportedLanguages" which delivers a list of enUS, deDE or whatever and your other methods may accept those languages and deliver the correct response. Or deliver all language versions and let the client sort it out. But this may be a bit network overkill depending on the number of supported locales...

In my opinion, WebServices should "stand on their own", the clients should be thin and not require lots of information to process the content. Imagine a C#-client, who may not be able to work with your Ressources or whatever. Or a new client without ressources not being able to work with your data...

Additionally, it could be different to really get the clients locale - a non-english person may use an english system or may be in an english country, but would like to see data in his native language. But if you really need to do this, I'm not aware of anything to enable this.

§对你不离不弃 2024-12-13 05:07:35

翻译是你们服务的主要目的还是只是为了方便用户?

对于后一种情况,我会反过来解决这个问题:

在您的应用程序设计中,是否可以以任何方式发送语言中立的消息(例如 service.fail 或类似的内容) )到客户端,并让客户端由于本地资源包而翻译它们?这将允许您的服务的独立用户将您的答案转换为他们想要的任何内容,包括使用 ResourceBundle 进行翻译。在我看来,显示适当消息是客户端界面的工作,而不是服务的工作。

当然,这样做的缺点是您将不再将资源包集中在一个地方。

至于你问题的另一面:ResourceBundle 是可行的方法,它是专门为该任务设计的。

另外:我不知道网络服务有什么方法可以了解其客户端的任何信息,除了直接拦截 Http-Request 并读取其字段(特别是 Accept-Language)。这些字段对 en-US 等语言进行编码。

Is the translation the main purpose of your service or is it just seen as a convenience to the user?

For the latter case I would kind of go about the problem the other way round:

Is it, in your application design, in any way possible to send language-neutral messages (like service.fail or something like that) to the client, and have the client translate them due to a local resource bundle? This would allow independent users of your service allow to transform your answer into anything they want, including translation using ResourceBundle. It is, in my eyes the job of the client interface to show the appropriate message, not the job of your service.

Of course, the downside of this is that you won't have your resource bundles all in one place anymore.

As to the other side of your question: ResourceBundle is the way to go, it has been specifically designed for the task.

Also: I am not aware of any way for a web-service to know anything about it's clients other directly intercepting the Http-Request and reading it's fields, specifically Accept-Language. These fields encode languages like en-US.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文