CodeIgniter 1.6.3 Maintenance and Security Release

[eluser]Derek Jones[/eluser]
No, we added it because it's a good fit. It's something we have used quite often in our development, and it's proven handy for us, so we thought we'd share it with CI. Obviously I can't speak to the point of what you use language files for in your development, but when building web applications, language variables are most commonly used for forms and UI elements. It's common enough that another function call seems silly and adds length to the code. This is a simple way to ensure that your forms are localized and accessible, and among a team of developers, the simpler you can make such things, the better; I'm sure there's at least one other team out there besides us that finds this useful. If you have a philosophical disagreement with it, no one will force you to use that feature, and it won't hurt you at all.

[eluser]xwero[/eluser]

language variables are most commonly used for forms and UI elements

What you are saying is that you use it on everything, are there any other than UI elements when displaying a page

Most part of my language strings creating a multi language site are titles and links. In the front end forms are nearly existing most of the time. In the back end forms are all over the place but then there are also legend tags, no selection options, ...
Like i said it can be convenient but it's too limited IMO.

[eluser]Derek Jones[/eluser]
Hey, I'm open to suggestions for improvement, xwero. There aren't any blinders on my eyes, it's just a useful pattern that we've developed and thought others might be in a similar position.

[eluser]xwero[/eluser]
Don't get me wrong Derek i can understand why you added it. CI is more your baby than it's mine anyway

I have the idea the libraries should be markup-less to make them more reusable. i understand your criticism about adding an extra function call but creating a helper for the language class has two advantages as i see it.
First you have less typing. $this->lang->line('someline') vs lang('someline')
Second you can make it more clear what the functionality is. $this->lang->line('someline','for') vs lang_label('someline','for')

A helper makes it possible to create functions like
lang_h('someline',1) -> <h1>someline value</h1>
lang_link('someline','controller/method','id="attrributes"') -> &lt;a href="http://site/url/controller/method" id="attributes"&gt;someline value</a>

[eluser]Référencement Google[/eluser]
I jump in the discussion, but I personally think generating labels should go in the Form Helper and not in the lang class that should be reserved only for language related things. Thought I would be glad to have a language helper as suggested by Xwero and in where we could have one function that generate labels.

I've done in the past something that is personally very handy for me: http://ellislab.com/forums/viewthread/75629/

[eluser]lynkyle[/eluser]
Thank you for this! Cheers!

[eluser]Derek Jones[/eluser]
@xwero - good suggestion, in fact, worthy of a quick live patch since this spent only a day or two even in the subversion. I've moved it to a helper and presently there is one function, lang(), which feels even more appropriate for use in view files. 1.6.3 has been retagged with this inclusion.

[eluser]AgentPhoenix[/eluser]
Derek, can you pass a language variable into this as well or will it just use the default language?

[eluser]Derek Jones[/eluser]
The lang() helper function works just like $this->lang->line() with the addition of the ability to output a form label, so no, it will output the language line from the loaded language(s).

[eluser]AgentPhoenix[/eluser]
Yep, momentary lapse on my part there. Haha! You're now free to return to your regularly scheduled programming. (No pun intended.)