Generally there should be no need to use non-English source language. I think it's better not to introduce artificial message IDs layer since it complicates both code and translation process.

This might be true for small or middle sized apps. But imagine you have translated and published the app in all major european languages (should be around 7, I guess). If you need to update the source language and all translated strings it's fine. But if you have to update the source language but none of the translations(misspelled, grammer fail, region specific, language based offer, etc...) you have to touch every file containing translations. This might be rare, but it takes a lot of time.

I think it should be an option to use faked keys or the real source language. A user should use what ever suits him best.

Quote

Also a native interface for translationmanagment (like gii) would be a good idea.translatephpmessage is mostly fine, but has some downsides and won't work with any other adapter.

This might be true for small or middle sized apps. But imagine you have translated and published the app in all major european languages (should be around 7, I guess). If you need to update the source language and all translated strings it's fine. But if you have to update the source language but none of the translations(misspelled, grammer fail, region specific, language based offer, etc...) you have to touch every file containing translations. This might be rare, but it takes a lot of time.

I think it should be an option to use faked keys or the real source language. A user should use what ever suits him best.

I agree with the use case of the fake source keys. I have in my projects at the moment about 10% of the text translated as a dynamic string passed to Yii::t() - I had to modify the "yiic message" so it does not delete or mark with @@ "removed" translation. Some sort of combined solution would meet all use-cases out there.
They can use just two different methods, say Yii::t() for regular translation and Yii::tk() for translating keyword-based texts.

Anyway there is reason to think this through and think of a better system, except the case of strings written in the source code.

I like Yii's advanced i18n features with the only exception being the lack of fake source keys.

There are several use cases where this feature comes in handy:

Homonymums and their different variants in other languages. You have to keep in mind that while there is a single word "know" in english, my language alone has several translations with contextually different meanings.

Sometimes english is not the native language of the developers and they might not know exactly what is the text's meaning and why is it where it is in the code, also you have to keep in mind that contrary to the best practices a lot of people use other language than english as their source language which makes it complicated in the moment when people of other nationality are introduced into the development process and there might be a need for switching the source language which is not an easy task to do once you have thousands of messages. The existence of fake keys from the beginning which have logical structure would prevent this problem.

Overall I don't see a reason why not have the option to use artificial language as a source language instead of english.