PHP6的未来
Yesterday was a quite thrilling day for the PHP development team and led to some imprecise news articles so let's take a look at what happened: Over
PHP开发团队杯具了。
the last months many of the core contributors agreed that the current approach to bring Unicode into PHP's engine wasn't the right approach and a
上个月，很多核心开发者一致认为把Unicode引进到PHP引擎中不是一件好事。
good thing would be to rethink it from the start. By a provocative move of one contributor the stalled situation got some more movement and
他们要从头考虑这件事。
Rasmus declared the current implementation to be discontinued to restart.
Rasmus(译者注：PHP的创始人)说当前的实现方式将会停止，这件事要从头开始做。
The past
过去
When the foundation of what should have become PHP 6 was created a decision was made to use UTF-16 as internal encoding for "everything" inside the engine.
PHP6创建之初，决定把UTF-16作为引擎内一切内容的内部编码
The choice for UTF-16 was made due to the fact that PHP 6 would use the ICU library which is focused on offering UTF-16 string functions.
选择 UTF-16是因为IBM公司的ICU库能够提供UTF-16编码的解决方案。
By using UTF-16 as default encoding we'd have to convert the scripq code and all data passed from or to the scripq (request data, database results,
把 UTF-16作为默认编码，我们必须把所有的数据都做一次转换，从另一种编码转过来或转过去。
output, ...) from another encoding, usually UTF-8, to UTF-16 or back. The need for conversion doesn't only require CPU time and more memory
转换不光需要更多的CPU时间和内存使用量 (UTF-16通常需要占用两倍于UTF-8的空间。)
(a UTF-16 string takes double memory of a UTF-8 string in many cases) but makes the implementation rather complex as we always have to figure out
并且当我们需要判断特定条件下哪种编码更合适时，还会使实现更加复杂化。
which encoding was the right one for a given situation. From the userspace point of view the implementation brought some backwards compatibility
从用户空间角度来看，这种实现打破了向后的兼容性。
breaks which would require manual review of the code. These all are pains for a very small gain for many users where many would be happy about a
不得不手工复审代码来让老代码重新工作。这一切都是弊大于利的。更多用户更愿意一种更紧凑的集成方式，比如像mbstring之类的函数。
tighter integration of some mbstring-like functionality. This all led to a situation for many contributors not willing to use "trunk" as their main development
这一切导致很多PHP代码作者不愿意使用主干代码作为他们的开发代码树。或者使用稳定版5.2或5.3,或者干脆拒绝做任何开发了。
tree but either develop using the stable 5.2/5.3 trees or refuse to do development at all.
The present
现在
Yesterday the stagnation created by the situation has been resolved and it was decided that our trunk in svn will be based on 5.3 and we'll merge
昨天前面的状况解决了，事情进入新的阶段，(PHP团队)决定我们的开发主干将基于5.3版本。features from the old trunk and new features there so that 5.3 will be a true stable branch. The EOL for 5.2 has not yet been defined but I suggest you
我们将会把老主干的新特性合并进来，所以，PHP5.3会是真的非常稳定的分支了。5.2版的生存期还不知道有多久，但是我真的建议大家移植到5.3版本
to really migrate over to 5.3, which usually can be done with very little work, as soon as possible.
这通常只需要很少的工作量。越快越好。
The future
未来
Right now we're starting different discussions to see what kind of Unicode support we really want. Many contributors react positive on a proposed
刚刚，我们开始了一个不同的讨论，想看看到底什么样的Unicode支持才是我们真正想要的。很多开发者赞同使用一个“字符串类”来封装Unicode形式
"string class" which wraps string operations in Unicode and binary forms without going deep in the engine. In my opinion such an approach might also
和二进制形式的字符串操作，而不深入到PHP引擎中。我认为这个方法十一个可行的办法，可以解决PHP字符串API中经常被批评的不一致性。(新代码使
be a way to solve some of the often criticized inconsistencies in PHP's string APIs without the need to break old code. (new code uses the new class,
old code the old functions) But that idea is far from a proper proposal or even the implementation, current status is about refocusing the development用新类，老代码使用老函数)。但是这个想法还只是一个想法，离实施还很远。当前状态是，重新把焦点放在开发上，进行需求和设计讨论。
and get the requirement and design discussions going. By that it's a bit early to decide whether the next version of PHP will be called PHP 5.4, PHP 6 or
因此，现在决定下一个版本叫什么还有点早，PHP5.4?PHP 6?甚至 PHP 7?
maybe even PHP 7.
PHP is alive and kicking!
无论如何，PHP现在还是活蹦乱跳的。不会那么容易死掉。