Silverlight 通过资源文件本地化字符串还是?

发布于 2024-12-03 10:40:55 字数 233 浏览 0 评论 0原文

关于如何实现 Silverlight 应用程序本地化的一般建议是什么?

我的第一个想法是,我们可以在资源文件或将本地化存储在数据库的资源表中进行选择。

每种方法的优点和缺点是什么?还有其他方法吗?

资源文件的渲染速度会更快并减少流量,因为您不需要从 Web 服务检索字符串。

从数据库来看,它可能更容易维护。

假设我们需要实现 3-4 种不同的语言。您会选择什么?为什么?

What are the general advice on how to implement localization of a Silverlight application?

My first thought is that we've got a choice between resource files or storing the localization in resource tables in the database.

What are the pro's and con's for each method? Are there other methods?

Resource files would be render faster and reduce traffic as you wouldn't need to retrieve the strings from a webservice.

From a database it might be easier to maintain.

Let's say we would need to implement 3-4 different languages. What would be your choice, ..and why?

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

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

发布评论

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

评论(1

顾北清歌寒 2024-12-10 10:40:55

我知道这会得到很多传统的答案,但我也想提出一些完全原创的东西,我们自己尝试(并成功)使用附加属性而不是绑定来更有效地本地化 Silverlight:

链接:完成后的 Silverlight 项目本地化

我们发现资源和绑定解决方案繁琐且不灵活因为它们都需要设置翻译在项目中(因此在更改时需要重新部署应用程序)。

传统上,翻译是批量发送的,并按语言进行管理(使用唯一的密钥、译者注释等)。 (有一些工具可以使资源转换变得更容易,但我们找到了更好的方法)。

我们的解决方案意味着我们在中央服务器数据库中管理本地化,但也可以在应用程序本身内提供本地化编辑器,供翻译人员在使用应用程序时使用。

资源的优点:

  • 小型项目易于管理
  • ,不需要额外的代码

资源的缺点:

  • 都需要重建/重新部署应用程序
  • 任何简单的语言更改 关于所有的绑定解决方案都有很长的字符串(这使 Xaml 膨胀)
  • 绑定解决方案为很少更改(或者更确切地说只是一次更改)的项目添加了巨大的通知开销
  • 使用未使用的语言下载 SL

数据库的优点:< /strong>

  • 中央存储库对于任意数量的语言
  • 通过下载新数据来更改语言(大型应用程序中每种语言最大 200kb)
  • 仅下载所需的语言并动态更改
  • 支持翻译人员在应用程序内编辑资源(不需要额外的 UI 表单)。

数据库的缺点:

  • 需要更多的初始设置工作
  • 需要数据库和匹配服务
  • 需要一种将翻译放入正确位置的方法(请参阅上面的链接了解我们的解决方案)

I know this will get a lot of traditional answers, but I would also like to put forward something completely original we tried (and succeeded) doing ourselves for more efficient localisation of Silverlight using Attached Properties instead of binding:

Link: Localisation of Silverlight projects after completion

We found resources and binding solutions to be tedious and not flexible as they all require the translations to be set in the project (and therefore needs a re-deploy of the app when it changed).

Traditionally translations are sent out in batches and managed by language (with unique keys, translator notes etc). (There are tools to make the conversion to resources easier, but we found a better way).

Our solution means we manage the localisation in a central server database but can also provide localisation editor, within the application itself, for translators to use while using the application.

Pros for resources:

  • Simple to manage for small scale projects
  • No extra code required

Cons for resource:

  • They require a rebuild/re-deploy of the app for any simple language change
  • The binding solutions about all have very long strings (which bloat the Xaml)
  • The binding solutions add a huge notify overhead for items that seldom change (or rather only change all at once)
  • Bloats SL download with unused languages

Pros for Database:

  • Central repository for any number of languages
  • Change language by downloading new data (max 200kb per language on large app)
  • Only download language required and change on the fly
  • Supports in-app editing of resources by translators (does require extra UI forms).

Cons for Database:

  • Required more initial work to set-up
  • Requires a database and matching service
  • Requires a means of putting the translations into the right places (see above link for our solution)
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文