• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
How do you i18n?

#11
[eluser]boldewyn[/eluser]
My line of thought is, that the selection of language has (ideally) nothing to do with routing to a specific content, therefore I do it at the CI_URI stage.

With "ideally" I mean, that on my site every page exists in every available language. Then a MY_URI class takes over URI handling, excerpts the language as being the first part of the uri_string, negotiates language w/ browser, if it's missing or not conforming and hands over a stripped version of the URI to the routing. It also saves the found language in the config for use with gettext.

Inside my application I use gettext (or, because PHP's gettext is horrible, <http://savannah.nongnu.org/projects/php-gettext/>).

Any comments about this way? I'd be glad to hear.

#12
[eluser]adamp1[/eluser]
Iv read alot about the gettext function, does anyone know if this how large websites do it?

#13
[eluser]boldewyn[/eluser]
Wordpress does it, so: yes, there are big sites using it. (I'm talking about the gettext surrogate at nongnu.org)

It seems to be quite performant, but don't ask me numbers...

#14
[eluser]adamp1[/eluser]
At the moment language files are really pissing me off. For several main reasons which I know solutions to but don't know which one would be best. So at the moment I'm sitting on the fence doing neither.

First off I want my application to be easily upgradable so I want all language strings to be editable if needed, this means I need to use some kind of language system. Now my system comprises of many modules each with their own language file which has specific strings that module uses.

Now say I have the line $lang['member_delete'] = "Delete";, now yes it is used in the member module but its also used in other places, but I don't want to load all language files every time. So basically what I have to do is create more $lang['modulename_delete'] = "Delete"; for each module which uses the word 'Delete'. So as you can see this starts to mean editing the word 'delete' in multiple locations.

So I thought maybe use gettext, and then even though 'Delete' is used in multiple locations they would all use the same meaning. But then comes the problem of having one very large language file which gettext uses, this means it looses its individual relations with each module.

So what I'm asking is how do people cope with using basic strings like 'Edit', 'Add', 'Delete' etc. Do you use the CI language files or gettext?

#15
[eluser]Référencement Google[/eluser]
Quote:So what I’m asking is how do people cope with using basic strings like ‘Edit’, ‘Add’, ‘Delete’ etc. Do you use the CI language files or gettext?

I personally have a general_lang.php file with all the common stuff like that, and I autoload it for all the application. Then for module specific languages, I make a specific file like contact_lang.php for example.

I was either thinking to build a kind of "dictionary" in a DB table witch will store all words and phrases of the site, but I don't know if it will be a good thing, something like:

Code:
word_ID | lang_ID | alias | word

#16
[eluser]esra[/eluser]
Personally, the lack of a decent i18n solution for CI is a pet peave of mine. It's something I have told myself was needed, but other priorities in life always seem to prevent it from happening.

The spagetti code in osCommerce sucks, but support for multiple languages in the core for both language strings and database content is fantastic. osCommerce supports both a default language (as does CI) and a current language. The 'current language' value is the language selected last by the end user during their previous visit (by selecting a language option from a view partial; an infobox in osCommerce terminology) and is stored in the user's cookie and the current session. Upon later visits to the same site, the cookie information is retrieved and used when opening subsequent sessions. With the existance of a global current language variable, the variable value can be used to determine which set of supported language strings to use and what language-specific database content to use.

I would imagine that the need for a current language was considered in the design of CI, but was not supported since sessions are optional. The current Language library was probably based on that requirement.

The trick to handling database content is to either include a foreign key for a language_id or to populate a language column with a idiom name from a select list, possibly generated by a helper from a languages array or config file. For something like the content table in a CMS, the content_id and language_id columns should be assigned to a unique key, or both fields should be treated jointly as a primary key for the content table, or primary/foreign key relationships can be used in queries. For osCommerce, common information that remained the same for all instances of content resided in one table and a second table was used to store language-specific instances of the content.

Following the above should provide the basis for application-specific i18n support. What's lacking to create a complete i18n solution is a Validation library which can conditionally use extended UTF-8 string handlers when required or mbstring when loaded by php.ini. You might note that the Kohana framework solved most of these issues, so a PHP4/PHP5 compatible solution for CI should be possible. The Language library also needs to be extended to support a current language value and a method should probably be provided to switch between languages based on current language selection.

Language selection can be handled in other ways. osCommerce provides a infobox (a partial or view fragment in CI terms) for language selection. It's also possible to automatically detect the users language using an IP locator (e.g., GeoIP) and code to determine the user's country based on their IP address. Earlier, a similar solution was used in the Rapyd library to detect the users language.

So, the underlying infrastructure for a decent i18n solution already exists at the system level. Writing extended Validation and Language libraries can solve the application-specific and module-specific aspects. Some helpers could be created to support extended UTF-8 string handlers by converting the php-utf8 string handlers on SourceForge (by Harry Fuecks) to CI helpers. The Validation library could use these helpers as well as your controllers and views.

#17
[eluser]andjules[/eluser]
[quote author="chestercheese" date="1204674012"]I'm trying to do it following the CI wiki instructions here:

But I've had no luck. I'm new to MVC and CodeIgniter, so maybe I'm just missing some small detail the the instructions, for example: ...

Even with my assumptions, I still can't get it to work. I must be missing something. 8-/[/quote]

chestercheese, I was figuring out those wiki instructions yesterday and I noticed some small issues with the code & instructions... I updated the wiki once I got it working, so give it another try and see if you get somewhere. Also, I think the instructions assume that index.php has been removed from the URLs via .htaccess (you can read about that in the user guide under CodeIgniter URLs).

#18
[eluser]Vicente Russo[/eluser]
Hi..

The wiki i18n solution doesn't work with templates, I guess, so I made a few modifications and posted on my blog a simple solution.

[quote author="andjules" date="1206560965"][quote author="chestercheese" date="1204674012"]I'm trying to do it following the CI wiki instructions here:

But I've had no luck. I'm new to MVC and CodeIgniter, so maybe I'm just missing some small detail the the instructions, for example: ...

Even with my assumptions, I still can't get it to work. I must be missing something. 8-/[/quote]

chestercheese, I was figuring out those wiki instructions yesterday and I noticed some small issues with the code & instructions... I updated the wiki once I got it working, so give it another try and see if you get somewhere. Also, I think the instructions assume that index.php has been removed from the URLs via .htaccess (you can read about that in the user guide under CodeIgniter URLs).[/quote]

Exactly. I had the same problem implementing that i18n, and I posted a solution that worked for me. I hope this could help!

:-P


Digg   Delicious   Reddit   Facebook   Twitter   StumbleUpon  


  Theme © 2014 iAndrew  
Powered By MyBB, © 2002-2021 MyBB Group.