Yii Framework Forum: I18N - Yii Framework Forum

Jump to content

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

I18N

#1 User is offline   andredelorme 

  • Junior Member
  • Pip
  • Yii
  • Group: Members
  • Posts: 48
  • Joined: 30-April 09

Posted 17 April 2012 - 05:56 AM

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
0

#2 User is offline   samdark 

  • Having fun
  • Yii
  • Group: Yii Dev Team
  • Posts: 3,642
  • Joined: 17-January 09
  • Location:Russia

Posted 17 April 2012 - 07:43 AM

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.
Yii 1.1 Application Development Cookbook

Enjoying Yii? Star us at github: 1.1 and 2.0.
0

#3 User is offline   andredelorme 

  • Junior Member
  • Pip
  • Yii
  • Group: Members
  • Posts: 48
  • Joined: 30-April 09

Posted 18 April 2012 - 08:08 AM

View Postsamdark, 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?
0

#4 User is offline   SapporoGuy 

  • Standard Member
  • PipPip
  • Yii
  • Group: Members
  • Posts: 177
  • Joined: 25-December 10
  • Location:Sappor Beer Refinery

Posted 18 April 2012 - 11:19 PM

"artificial messge ID layer"

Could you explain more what you mean by that?
0

#5 User is offline   samdark 

  • Having fun
  • Yii
  • Group: Yii Dev Team
  • Posts: 3,642
  • Joined: 17-January 09
  • Location:Russia

Posted 19 April 2012 - 04:22 AM

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.
Yii 1.1 Application Development Cookbook

Enjoying Yii? Star us at github: 1.1 and 2.0.
0

#6 User is offline   Suralc 

  • Junior Member
  • Pip
  • Yii
  • Group: Members
  • Posts: 48
  • Joined: 10-January 12
  • Location:Germany

Posted 27 April 2012 - 05:19 AM

View Postsamdark, 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.

2

#7 User is offline   andredelorme 

  • Junior Member
  • Pip
  • Yii
  • Group: Members
  • Posts: 48
  • Joined: 30-April 09

Posted 27 April 2012 - 05:44 AM

View PostSuralc, 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.
2

#8 User is offline   Psih 

  • Standard Member
  • PipPip
  • Yii
  • Group: Members
  • Posts: 114
  • Joined: 30-June 10

Posted 27 April 2012 - 07:49 AM

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.
2

#9 User is offline   SapporoGuy 

  • Standard Member
  • PipPip
  • Yii
  • Group: Members
  • Posts: 177
  • Joined: 25-December 10
  • Location:Sappor Beer Refinery

Posted 27 April 2012 - 08:25 AM

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.
0

Share this topic:


Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users