| Poll: URI language identifier in core? You do not have permission to vote in this poll. |
|||
| yes | 22 | 52.38% | |
| no | 11 | 26.19% | |
| maybe | 9 | 21.43% | |
| Total | 42 vote(s) | 100% | |
| * You voted for this item. | [Show Results] |
| Add URI Language Identifier to core? |
I understand your concerns. And I know there are many ways to handle multilingual.
What I am suggesting is CI can build this common way into the core. And it's of course optional. You can still choose your favorite way to handle the language. Imagine Apple is going to build the web with CI and have this: http://www.apple.com/hk/ipad/compare/ http://www.apple.com/sg/ipad/compare/ hk and sg as language. ipad as controller. compare as method. And maybe Samsung: http://www.samsung.com/hk/business/ http://www.samsung.com/sg/business/ HTC also: http://www.htc.com/hk-tc/accessories/ http://www.htc.com/sea/accessories/ I'm not forcing anyone to use this method nor saying this method is better than yours. I just want to say it's common. But there is no clear guide for implementing this common convention in my CI project. As you can see this convention build something on the traditional "/controller/method" url which is something about core routing. That's why I would like this convention to be build into the core. For example: Blog controller has two methods: users, comments. $route['blog/joe'] = 'blog/users/34'; http://sample.com/blog/comments (Redirect to default language maybe) http://sample.com/hk/blog/comments http://sample.com/sg/blog/comments All are accessing the comments method in Blog controller. And a helper function (or global variable or anything) let us know which language is it. Then we can load the correct language. http://sample.com/blog/joe (Redirect to default language maybe) http://sample.com/hk/blog/joe http://sample.com/sg/blog/joe All are accessing the users method with parameter 34 in Blog controller.
One of the reasons you wouldn't necessarily build this convention into CI as an option is that many of the companies you reference probably do this at a level above whatever framework they are using for their website. For example, if you go to http://www.apple.com/hk/ipad/compare/, you might be internally routed to a completely different server from the one which serves http://www.apple.com/sg/ipad/compare/
Since there could be differences in product lines and launch dates (in addition to the language differences), each country or region could have different requirements for load balancing at different times, and you may have more servers available near a particular region to serve that region's content. For a small site, obviously, this wouldn't be the case, so it's nice to be able to handle it within the framework. However, there are a number of different ways to handle this problem, and almost all of them would require some amount of extra configuration for the sites that need it, and would not only be useless overhead for the sites that don't, but may needlessly restrict what they can do.
This is where using routes would be better.
Good news is that's already built in. Your also extend the router class with you own MY_router.php and handle it your self there automatically
04-20-2015, 09:33 PM
(This post was last modified: 04-20-2015, 10:55 PM by ivantcholakov. Edit Reason: Grammar )
I appeal to natural English speakers to think twice before saying "No", because this feature usually is not important for them.
Quote:I voted No, because I do not want the framework to dictate how I choose to handle multi-language implementations. This is absurd sentence .. How you handle languages in a PHP script ? with CSS / JS or with PHP ? And if you use CI for your PHP code why not to have an easy option to manipulate languages? And at the end, you are always are free not to use it  but to think for another faster and better way to handle languages..
Best VPS Hosting : Digital Ocean
(04-21-2015, 06:47 AM)sv3tli0 Wrote:Quote:I voted No, because I do not want the framework to dictate how I choose to handle multi-language implementations. Like query strings? Language subdomains (i.e. en.example.com; this is more common for large companies)? Stored in a cookie or session variable (possibly even on top of a user profile setting)? The HTTP Accept-Language header (in fact, this is the only method that you can argue to be a standard)? There are many ways and preferences on how to implement this, and there's nothing absurd about the statement that you quoted. (04-20-2015, 09:33 PM)ivantcholakov Wrote: I appeal to natural English speakers to think twice before saying "No", because this feature usually is not important for them. Honestly, the language I speak has nothing to do with the importance of this feature. No matter how much (or how little) I want to support multiple languages on my website(s), it only happens if my employer/client can supply their content in multiple languages. I happen to know enough of two foreign languages to know that I have no business attempting a full translation of content into either of them. This feature is based on a practice which has changed over time and is likely to continue to do so. What is the advantage of putting this functionality into the core? What are the disadvantages? Should the various potential language identifiers be reserved routes? Which standards should be followed? (How do you distinguish between versions of English, French, Spanish, and Portuguese, since those of us in North/South America don't tend to use the original versions of these languages?) The issues of identifying languages and their variants aren't well handled by the Lang class itself, in my opinion, so I do tend to take issue with the idea that we should just jump right in and add language identifiers to the core routing.
@mwhitney
"Which standards should be followed? (How do you distinguish between versions of English, French, Spanish, and Portuguese, since those of us in North/South America don't tend to use the original versions of these languages?)" CLDR - http://cldr.unicode.org - language codes could be taken from there. I did this for the languages that CodeIgniter 3 currently supports - https://github.com/ivantcholakov/starter...g/lang.php Language URI segment may differ slightly if you wish for aesthetical reasons, it is configurable. If only one (the default) language is enabled, the framework behaves as it behaves now, without the feature. It is matter of configuration (without touching routes.php in CI3). (04-21-2015, 08:23 AM)ivantcholakov Wrote: CLDR - http://cldr.unicode.org - language codes could be taken from there. I did this for the languages that CodeIgniter 3 currently supports - https://github.com/ivantcholakov/starter...g/lang.php So you chose a corporate extension to multiple existing standards, but didn't actually follow the format provided? Examples: Brazilian Portuguese in CLDR is pt_BR, Latin American Spanish is es_419. Why did you choose to use the identifier for Taiwan in the latter part of the URI segment for Traditional Chinese? Using the U.K. flag for U.S. English is one of my favorite things to see in someone's code when they're commenting on the handling of languages by English-speaking people. These examples point out some of the issues I see with trying to integrate this into the core. Ideally, the Lang class itself would have better handling of standard language tags. If they could be handled properly by the Lang class, it would be much easier to modify the routing to properly handle language tags. At that point, the system should be able to handle language tags in any number of formats, preferably with configurable choices between '-', '_', and '/' for the separators used between language tags and subtags as well as configuration of default language choices for the general tags as well as the lack of language tags, since all of these impact the ability to use those language tags with varying standards and extensions (or for use in a URL routing scheme).
@mwhitney
Q "So you chose a corporate extension to multiple existing standards, but didn't actually follow the format provided? Examples: Brazilian Portuguese in CLDR is pt_BR, Latin American Spanish is es_419." A I took the values from the JSON files, codes there are with dashes (pt-BR, es-419), here is copy/paste of the English one: Code: {------------- Q "Why did you choose to use the identifier for Taiwan in the latter part of the URI segment for Traditional Chinese?" A http://en.wikipedia.org/wiki/Traditional...characters - "They are most commonly the characters in the standardized character sets of Taiwan, of Hong Kong and Macau or in the Kangxi Dictionary." ----------------------- Q "Using the U.K. flag for U.S. English is one of my favorite things to see in someone's code when they're commenting on the handling of languages by English-speaking people." A It is not recommendable using flags for language identification at all, but I am doing this because of tradition, clients might push me this way. Consider the "flag" field as a customization, it is not to be implemented within a framework, the set of the flag images are not to be put within the framework too. And, in North America you can use the American flag, in Europe you can use the English flag if flags are to be shown. --------------------------- "These examples point out some of the issues I see with trying to integrate this into the core. Ideally, the Lang class itself would have better handling of standard language tags (http://www.w3.org/International/articles/language-tags/). If they could be handled properly by the Lang class, it would be much easier to modify the routing to properly handle language tags." Re: CLDR-codes are used by intl PHP extension, this is why I prefer them. I think, there are no significant differences with http://www.w3.org/International/articles/language-tags/ (dashes instead of underscores there too). ---------------------------------- "At that point, the system should be able to handle language tags in any number of formats, preferably with configurable choices between '-', '_', and '/' for the separators used between language tags and subtags as well as configuration of default language choices for the general tags as well as the lack of language tags, since all of these impact the ability to use those language tags with varying standards and extensions (or for use in a URL routing scheme)." Re: I agree with this, but to some degree, in this area it is easy to come to something quite complicated. Routing by language segment implementation actually is the easy part. Dashes or underscores - this is solvable, it is not quite important now. The tricky part is how external components (PHP or JavaScripts) identify languages, well, they do this in different ways: PHPMailer - https://github.com/PHPMailer/PHPMailer/t...r/language CKEditor - https://github.com/ckeditor/ckeditor-dev...aster/lang Datatables - https://github.com/DataTables/Plugins/tree/master/i18n etc. Translation between language identifiers is inevitable. This is how I approach to this, an example: Code: 'portuguese' => array(For Brazilian Portuguese PHPMailer uses a non-standard language identifier, so I extend the configuration for this language with an additional field "phpmailer" that holds this non-standard id. Of course, the default framework configuration will not have such data, it could support this logic however. |
