Menu
▾
▴
scrollkeeper-devel
|
From: <las...@Su...> - 2001-05-17 09:48:27
|
Hi, This is mostly finished now, I have on issue to be sorted. The fallback is basically a merge of trees according to a couple of locale related environment variables. The ones I consider are LC_MESSAGES, LC_ALL and LANG. I take the locale list from whichever is first set (in the order described previously) and use that. E.g. if LC_MESSAGES is da:de:en_US then these three category trees plus the C locale tree at the end get merged and the result is returned. What doesnt happen is to try to find partial locale trees if the full locale ones are not available. Example: if LC_MESSAGES is es:pt_BR:C then I check for es, pt_BR and C, but I dont check for pt if pt_BR is not there. Do people think this is ok or it should be changed (so that it would check for pt if pt_BR is not there)? Thanks, Laszlo |
|
From: Laszlo K. - S. I. <las...@su...> - 2003-08-22 12:13:42
|
Hi, Here is another one. Scrollkeeper is designed to fall back to translated locales if docs are not translated to the current locale. setlocale() (in libs/i18n.c) is used to identify the desired fallback path with the C locale sticked to the end (so that we fall back to English if all else fails). But if we are in a locale like ja_JP.UTF-8, the Sun i180n team is telling me that we should be able to fall back to a ja or ja_JP if ja_JP.UTF-8 is not available (before falling to English). This should be the case even if setlocale() only returns ja_JP.UTF-8 (as opposed to ja_JP.UTF-8:ja_JP:ja). I know this is not implemented right now. Is this how people think it should work? Or some other way? Please comment, Laszlo |
|
From: Malcolm T. <ma...@co...> - 2003-08-23 03:48:37
|
Hi Laszlo, On Fri, 2003-08-22 at 22:12, Laszlo Kovacs - Sun Ireland wrote: > Here is another one. Scrollkeeper is designed to fall back to translated > locales if docs are not translated to the current locale. > > setlocale() (in libs/i18n.c) is used to identify the desired fallback > path with the C locale sticked to the end (so that we fall back to > English if all else fails). > > But if we are in a locale like ja_JP.UTF-8, the Sun i180n team is > telling me that we should be able to fall back to a ja or ja_JP if > ja_JP.UTF-8 is not available (before falling to English). This should be > the case even if setlocale() only returns ja_JP.UTF-8 (as opposed to > ja_JP.UTF-8:ja_JP:ja). I know this is not implemented right now. Is this > how people think it should work? Or some other way? This should already be happening. I added some code back in September of last year (9/9/2002) to do this sort of stuff and it has been tested fairly thoroughly (since it affects the GNOME help system, for example). The code in question is in libs/i18n.c and should work exactly as you describe. This should have been in the 0.3.12 release. Now, it may not be being called in all the correct places, but as soon as we identify those, then it should be easy to fix up. I am going to release 0.3.13 very shortly (and probably 0.3.14 pretty soon thereafter to include whatever bug fixes are reported from the first release for a while). So if there are problems like this, encourage the Sun guys to whack them into Sourceforge's bug tracking system (as evil as it is, it's still a good place to track these problems) and I shall attend to them as soon as possible. Cheers, Malcolm |
|
From: Malcolm T. <ma...@co...> - 2003-08-23 04:07:04
|
On Sat, 2003-08-23 at 13:48, Malcolm Tredinnick wrote: > Hi Laszlo, > > On Fri, 2003-08-22 at 22:12, Laszlo Kovacs - Sun Ireland wrote: > > Here is another one. Scrollkeeper is designed to fall back to translated > > locales if docs are not translated to the current locale. > > > > setlocale() (in libs/i18n.c) is used to identify the desired fallback > > path with the C locale sticked to the end (so that we fall back to > > English if all else fails). > > > > But if we are in a locale like ja_JP.UTF-8, the Sun i180n team is > > telling me that we should be able to fall back to a ja or ja_JP if > > ja_JP.UTF-8 is not available (before falling to English). This should be > > the case even if setlocale() only returns ja_JP.UTF-8 (as opposed to > > ja_JP.UTF-8:ja_JP:ja). I know this is not implemented right now. Is this > > how people think it should work? Or some other way? > > This should already be happening. I added some code back in September of > last year (9/9/2002) to do this sort of stuff and it has been tested > fairly thoroughly (since it affects the GNOME help system, for example). > The code in question is in libs/i18n.c and should work exactly as you > describe. This should have been in the 0.3.12 release. Aah ... light dawns on marble head! They (your docs and build guys) may well not be using this release, since that particular bunch of code used strndup(), which I had not realised at the time was a GNU extension and hence not in libc on Solaris (or *BSD amongst others). That bug has probably been reported a dozen times since then. :-( [Although I seem to remember that two of the bug reports came from @sun.com, so somebody is testing things.] I removed the strndup() usage a while ago, and have had some reports that it now builds on those boxes. So if the case it just that Sun are still using the 0.3.11 release, please either test the CVS version or wait a few days until 0.3.12 comes out and try that. Cheers, Malcolm |
|
From: Laszlo K. - S. I. <las...@su...> - 2003-08-26 15:39:18
|
Hi Malcolm, You are right. I have to confess I haven't looked at the CVS before writing this email (my mistake). And we indeed use 0.3.11. So we will have to upgrade to 0.3.13 when it is out. Thanks for the help, Laszlo > This should already be happening. I added some code back in September of > last year (9/9/2002) to do this sort of stuff and it has been tested > fairly thoroughly (since it affects the GNOME help system, for example). > The code in question is in libs/i18n.c and should work exactly as you > describe. This should have been in the 0.3.12 release. > > Now, it may not be being called in all the correct places, but as soon > as we identify those, then it should be easy to fix up. > > I am going to release 0.3.13 very shortly (and probably 0.3.14 pretty > soon thereafter to include whatever bug fixes are reported from the > first release for a while). So if there are problems like this, > encourage the Sun guys to whack them into Sourceforge's bug tracking > system (as evil as it is, it's still a good place to track these > problems) and I shall attend to them as soon as possible. > > Cheers, > Malcolm > |
|
From: Dan M. <d-...@uc...> - 2001-05-18 15:58:52
|
Hi, I thought I would forward Laszlo's question to the mailing list for GNOME translators so they could comment. To put a little context around this for anybody who isn't following ScrollKeeper: ScrollKeeper is being used to populate the help browser wit= h a list of documents available. Because many locales do not have all documents translated, Laszlo is allowing for locale fallback. This way one can list the order of preference of locales. If the document isn't available in your first choice locale, it goes on to see if it is available in your second choice, ... Dan On Thu, 17 May 2001, L=E1szl=F3 Kov=E1cs wrote: > Hi, > > This is mostly finished now, I have on issue to be sorted. The fallback > is basically a merge of trees according to a couple of locale related > environment variables. The ones I consider are LC_MESSAGES, LC_ALL and > LANG. I take the locale list from whichever is first set (in the order > described previously) and use that. > > E.g. if LC_MESSAGES is da:de:en_US then these three category trees plus > the C locale tree at the end get merged and the result is returned. Wha= t > doesnt happen is to try to find partial locale trees if the full locale > ones are not available. Example: > > if LC_MESSAGES is es:pt_BR:C then I check for es, pt_BR and C, but I > dont check for pt if pt_BR is not there. Do people think this is ok or > it should be changed (so that it would check for pt if pt_BR is not > there)? > > Thanks, > > Laszlo > > _______________________________________________ > Scrollkeeper-devel mailing list > Scr...@li... > http://lists.sourceforge.net/lists/listinfo/scrollkeeper-devel > |