From: alex b. <en...@tu...> - 2001-06-08 06:47:02
|
hi all, more thinking about how to deal with multiple languages in the source tree... I'd like to see what people think of some of these ideas: -if you have a single 'master' source file, which has language keys in it (like: $foo="<lang>file.id</lang>"; those are just made into standard files within make: binarycloud/ make/ binarycloud/ user/en/foo.php user/fr/foo.php from the same original source file: user/foo.php -if you need to actually have variant _logic_ for different languages (a rarer case, but nonetheless important) - we have decided on a naming scheme like this: FileName.php FileName.fr.php (for a french variant of the source file, which will replace FileName.php in the fr/ tree in the make directory) -for resources (gifs,js,and css that browser include), we have decided on a fairly simple solution to the problem of multiple asset bases (different CSS for Japanese than English sites, different gifs, etc: all "browser referenceable" assets, including CSS, javascript, and gifs must be placed in user/htdocs/resources/ when you write templates in the source tree, you'll use <img src="/resources/images/foo/foo.gif">. That will be taken by the makefile, and ripped into each language specific source tree as: <img src="/resources/en/images/foo/foo.gif"> or <img src="/resources/fr/images/foo/foo.gif"> etc. the idea here is to avoid this: <img src="/resources/<?=BC_LANG?>/images/foo/foo.gif"> because that's messy and inconvenient. the only ramification is that you have to be willing to store your stuff under user/htdocs/resources (or you have to change the makefiles and run variants) the contents under resources would function much the same way as the rest of the stuff in the source tree: resources/images/foo.gif would just be copied by the makefile into each resources/LANG/images/foo.gif but if there was: resources/images/foo.gif and resources/images/foo.fr.gif then we would copy foo.gif to all the languages except fr, and when we come across fr, the foo.fr.gif _replaces_ foo.gif. --------------- I expect most of the source variants actually to be images, because our language (string) keying system will be quite flexible, and you should rarely need to write code that is actually language specific at the logical level. _alex |
From: Gokhan T. <mir...@tr...> - 2001-06-08 08:56:50
|
Hi all, I am the one of the poor Turkish guy have to fight with bloody localization issues and i believe there are too many non English citizens of the world have the same pain in the ass. Directory based language structure is very good for now to the homo sapiens high level technology :=) Very useful for images and files. i'd like to follow <img src="/resources/fr/images/foo/foo.gif"> It is clear and not affects the flow. CSS idea is good. It helps to solve most of the problems but what about a stuff like OK, Cancel, next, preview buttons etc.? If we don't use images there is a big trouble waiting. In Phpnuke, fellows used the translate method and separate language files. Seems okay but make it slow the all code and site. I am still looking the right solution on it. I want to talk about two other major problems. 1. Sorting tables in specific language. 2. Date time trouble. I know that we should deal with OS and software specific issues about them. But i strongly prefer to stay in cross platform as could as i do. Any comments about them? Cheers, Note: Of course i am ready to translate parts to Turkish :=) Gokhan |
From: Alex B. <en...@tu...> - 2001-06-08 17:08:21
|
> Hi all, > > I am the one of the poor Turkish guy have to fight with > bloody localization issues and i believe there are too many > non English citizens of the world have the same pain in the ass. > > Directory based language structure is very good for now to the homo > sapiens high level technology :=) Very useful for images and files. > > i'd like to follow > <img src="/resources/fr/images/foo/foo.gif"> > > It is clear and not affects the flow. > > CSS idea is good. It helps to solve most of the problems but what > about a stuff like OK, Cancel, next, preview buttons etc.? If we don't > use images there is a big trouble waiting. > In Phpnuke, fellows used the translate method and separate language > files. Seems okay but make it slow the all code and site. > I am still looking the right solution on it. The above is exactly what we do: resources/images/foo.fr.gif and foo.de.gif in the source tree are: resources/fr/images/foo.gif and resources/de/images/foo.gif in the make tree. > I want to talk about two other major problems. > > 1. Sorting tables in specific language. > 2. Date time trouble. > > I know that we should deal with OS and software specific issues about them. > But i strongly prefer to stay in cross platform as could as i do. 1: sorting, as I think the only way to deal with charsets properly is to put everything in utf-8, that means sorting would be a function of char order in utf, which I have admittedly little experience with. date/time is much easier, as you can standardize the dates you store in the DB, and use simple routines to display dates differently. i.e. you use "date/time" format in presentation only, all data storage is homogenous. > Note: Of course i am ready to translate parts to Turkish :=) cool! :) _alex |