2016 Unicode Conference拾遗（四）

最新推荐文章于 2024-06-08 11:58:58 发布

原创最新推荐文章于 2024-06-08 11:58:58 发布 · 8.1k 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#unicode conference

PHP 专栏收录该内容

1 篇文章

订阅专栏

介绍了一种通过独立WebService实现的动态翻译更新方案，该方案能够即时更新翻译内容且不受产品发布周期限制，提高了本地化效率。

在2016 UC上，除了和Kat Momoi先生非常有共鸣外，另外一个topic跟我们正在实现的框架也出奇的神似——Real-Time Localization Updates with Web Services，speaker是来自Adobe的Tarrence Egbert先生。

首先他介绍了自己团队是如何开发并使用这个L10n专属的web service来实现动态翻译更新的，特点总结如下：

· 这是一个对UI NL String进行翻译、存储和传递的框架

· 开发人言可以通过代码调用该框架

· 可以随时对网页上的翻译内容进行动态更新

· 从而达到让客户和产品团队对本地化内容感到更加满意

基本架构如下图：

传统模式下，在翻译过程中常见的问题包括：

· 花费时间太长，完全无法做到实时更新

· 不够灵活，正在固定的时间点或时间段内check-in resource文件

· 当面对不同技术和框架时，针对同样的字符串读取问题，Dev不得不用采用不同的办法。无形中加大了出错的概率

那么当使用了独立的Web Service后，什么样的L10n问题得到了有效解决呢？

· 翻译内容可以随时更改，并立刻生效

· 翻译不再依赖于核心产品代码发布时间表

· 标准化的Service调用方式，屏蔽了技术细节，所有产品都可以采用同样的方式进行调用

简而言之，就是要彻底解除L10n跟产品代码的耦合关系，将其作为一个单独的service独立出来。Dev只负责产品的功能开发，有自己独立的代码库，无需担心L10n的文件进入而导致的build error问题；而L10n部分也有自己需要维护的字符库，对外只暴露REST API接口，不再考虑产品的具体技术实现。

对于该观点，我个人举双手双脚赞同。站在dev的角度，负责translation的pm总是向我的代码库不断的check-in，一旦配置文件中的任何一处遗漏，都会导致编译错误 + build失败。这极大的降低了开发效率！站在L10n PM的角度，我只不过是想更换几个翻译string，让翻译更符合UI context而已，但check-in的时间点都被限定的很死，常常会遇到过了这个村就没这个店的情况。而一旦使用了独立的NL service，这些问题都将不复存在。

使用NL Service的示例代码如下：

function getAllDoc($locale)
{
                $url= "http://localhost:8080/lib/address/" . $locale ."/document";
                $_ch= curl_init();
                curl_setopt($_ch,CURLOPT_HEADER, FALSE);
                curl_setopt($_ch,CURLOPT_RETURNTRANSFER, TRUE);
                curl_setopt($_ch,CURLOPT_URL, $url);
                $result= jason_decode(curl_exec($_ch)) ;
                $httpCode= curl_getinfo($_ch, CURLINFO_HTTP_CODE);
                curl_close($_ch);
                return$result;
}
 
$doc = getAllDoc($locale);

返回的JSON文件示例：

echo "<h2>" .$doc->address . "</h2>";
echo "<div id='intro'>" .$doc->intro . "</div>";
echo "<table bordercellpadding=3>";
echo "<tr>";
echo "<th class='name'>" .$doc->name . "</th>";
echo "<th class='phone'>" .$doc->phone . "</th>";
echo "<th class='email'>" .$doc->email . "</th>";
echo "<th class='action'>". $doc->action . "</th>";
echo"</tr>";

说了很多该模型的优点，那么它的缺点又如何呢？个人认为大概有以下几点吧。

· 整体性能势必有所下降，对于有着实时要求的系统请慎用

· 独立出来的NL service务必保证服务的高可用性，否则一旦出现down机情况，用户很可能看到空白页面

所以综合看来，该模型对于系统响应时间要求不高，但对于翻译质量有要求，同时可能会频繁改动翻译内容的产品来说，应该是一个不错的选择。