依赖 setlocale 并依赖安装的语言环境是否可行?
我试图用 strftime 生成一个本地化的日期字符串，我使用的占位符是 %x.语言/区域设置是 setlocale(LC_ALL, array('jp','japanese'))，但是两个区域设置都不可用，因此它生成了一个包含不正确字符的字符串.然后我安装了 ja_JP.utf8 语言环境并将其指定为数组中的第一个元素，并且我遇到的日期格式问题得到了解决.
I was trying to generate a localized date string with strftime, the placeholder I use is %x. The language/locale is setlocale(LC_ALL, array('jp','japanese')), however neither locale was available so it generated a string with improper characters. I then installed the ja_JP.utf8 locale and specified that as the first element in the array and the date formatting issue I had was resolved.
我的问题是，我应该始终依赖安装的语言环境吗?我知道如何将它们安装在我有 root 访问权限的盒子上，但是如果我没有访问权限怎么办?
My question is, should I always rely on locales being installed? I'm aware of how to install them on boxes I have root access to, but what if I don't have access?
我相信 Zend_Locale 和 Zend_Translate 根本不依赖 setlocale 而是以某种方式在内部进行，这给我的印象是'对于企业级应用程序实际上是不可行的.
I believe Zend_Locale and Zend_Translate do not rely on setlocale at all but somehow do it internally, which gives me the impression that it isn't practically feasible for enterprise level applications.
我知道我可能会在我的应用程序中使用 Zend_Locale 和 Zend_Translate 但它也需要支持 PHP4，至少再支持一年，这就是为什么我不能单独依靠那些.
I know I could probably use Zend_Locale and Zend_Translate in my application but it also needs to support PHP4, at least for another year which is why I can't solely rely upon those.
推荐答案
如果我对 setlocale() 的检查是正确的，那么答案是:No and no.安装的语言环境的范围各不相同，它们的名称也是如此，并且最终无法完全确定地预测某个语言环境的可用性.
If my examination of setlocale() is correct, the answer is: No and no. The range of installed locales varies, as does their name, and the availability of a certain locale ultimately cannot be predicted with total certainty.
相关文章