[andredelorme]

Hi Yii Dev Team,

Will Yii 2.0 have an way to change messages for the sourceLanguage without having to modify the source code and consequently all translation keys?

Something as mentioned on this wiki article?
How to translate and do the translations the easy way

And what about dates and numbers validators, they will recognize current locale format?

Thank you

[samdark]

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.

[andredelorme]

samdark, on 17 April 2012 - 07:43 AM, said:

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.

OK, thank you samdark.

And what about dates and numbers validators based on target language formats?

[SapporoGuy]

"artificial messge ID layer"

Could you explain more what you mean by that?

[samdark]

andredelorme
Ideally they should.

SapporoGuy
I've mean same as in the article linked in the first post. Using non-existing language code as source and calls like

echo Yii::t('app', 'there.is.an.error');

It will require English at least translation file.

[Suralc]

samdark, on 17 April 2012 - 07:43 AM, said:

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.

[andredelorme]

Suralc, on 27 April 2012 - 05:19 AM, said:

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.

Have both options is a great approach.

[Psih]

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.

[SapporoGuy]

Translation takes time and money.
I want to save both

I would love a dual call method:
A.) call all standard phrases/verbs
B.) call translation for current page

This would allow group A to be heavily cached since it will hardly change. Group B is more dynamic since it depends on the nature of the page

Group a could also be tuned by the community and offered as part of the distro like the demos. This will allow to be multilingual on a limited scale from the start.

Group B is user specific so not that different as now.


I'm a big fan of psuedo_keys in the source, especially if a dev has offered their hardwork for others to use. So even if I can't read the diocumentation I can still benefit from the app.

Also, it reduces redundant translations which save me money and time.

Here is an example:
Edit entry
Edit name
Edit file
Edit page

I'd just round it down to: text_edit >> "edit"

Log into our site
Log in to edit
Log in

text_login >> "log in"

Group A does require effort but uniformity, multiple languages, and a base practice really makes this appealing.