Re: [Phpslash-devel] Re: [minor annoyance in new release

[Joe S. <joe...@us...>]

On Tue, Mar 04, 2003 at 07:46:32PM -0500, Luis M wrote:
> <snip>
> >On Mon, Mar 03, 2003 at 10:09:01AM -0500, Luis M wrote:
> > >
> > > I found this to be a little annoyance which might or might not be a bug. 
> >The
> > > templates under $PATH/templates/en/ are only offer under the "skin" 
> >block to
> > > the browsers who have English languages (en). Thus if you, say, have a
> > > $PATH/fr/skin1 directory for the french language (and the same for other
> > > languages) only that skin is offer to french browsers.
> >
> >Yes, I think I follow this now.  This is one reason you don't want to
> >cache the skin block.  Another is you get links to articles, etc.
> >
> >This is the designed behavior.
> >
> 
> good to know. I noticed the same kind of behaviour for the "Votes" block. If 
> a user in a different language goes to the site, and happens to go after the 
> cache for this block has time out, then the next time I go with a different 
> language I see the block in whatever the last language it was cache. To 
> avoid this, I set the cache to 0 -- I remember that setting a block's cache 
> to 0 used to cause problems in earlier versions of phpSlash. In any case, 
> setting this to zero helps, but doesn't solve the problem ... more on this 
> later on...
>

The previous problems turned out to be almost entirely caused by a memory 
allocation bug in php4.06.  Reducing the number of blocks updating at one 
time reduced the chance of hitting the bug.
 
> > > Since the text for the whole site gets translated regardless of the skin
> > > being used, I think it would make more sense to offer all templates from 
> >a
> > > given directory (or have a folder which is the default language for all
> > > other -- I think this is what "en" is).
> >
> >Uh, some templates contain text that is not translated - the submission
> >form, login form, poll results, etc.
> 
> True. But, eventually they will be able to translate from the "gettext"-like 
> functions phpSlash uses, right? In any case, only a few strings are left 
> out.
> 

I don't know about this.  The templates are pretty free-form for you to 
modify.  Seems to me it would be better to translate the text in its 
proper context.

> >
> > > Either that or users will have to
> > > create a directory in e/a directory for the language they want to 
> >support
> > > and put a "skin.ini" file whose skin.parent is the default language for 
> >the
> > > given site.
> >
> >Yes.  Except you can't refer back to the default language's skin
> >(yet, maybe?) in the skin.ini.
> >
> 
> yes you can :-) it's tricky thought. You have to use 
> "skin.parent=../../en/basic"; but it works. I'm doing this now. I hope that 
> it's not possible to pass something like this in the actual URL. If not 
> users will be doing things like "skin=../../../../../../../../etc/passwd" 
> and who knows what can happen. I have not tried to break the installation by 
> doing all illegal things I can think of, but I will very soon. I will report 
> whatever I find.
> 

This will probably not work in the future and instead more directives will 
be added to the skin.ini file such as parentlanguage.

Try to break stuff as suggested.  It should be protected.

> > > I know that modifying the algorithm for the "skin" blocktype could 
> >easily
> > > yield to recurring thru a list of duplicated directories, so a solution
> > > should involved default-ing to just one directory and not to all other
> > > languages to look for template directories that are not present in the
> > > current language... (confusing uh, just read this paragraph again...).
> > >
> > > I hope that this makes sense to you guys out there (Joe?).
> > >
> >
> >I think I understood after reading it a few times :)
> >
> >Setting the skin using the user accounts and preferences hopefully will
> >be the preferred method to choose skins.  However, I have done no testing
> >on what skins are available after a language change.
> >I think this might be broken.
> >
> 
> I knew it was confusing to write it, so it had to be worse to understand it.
> I have not tried to register a "normal" user account and changing the users' 
> preferences. Will users be able to see all skins regardless of language 
> settings and the directories used to placed the skins?
> i.e. skins in $templates/en $templates/fr $templates/lang will all show as 
> options to the users?

The language choices shown are for all text translations available.

The skin choices shown should be for the current language displayed ( if 
available).  It does not do this currently.  It still displays the default 
language's skin.  This is broken.  The skins block seems to do the same 
thing for me.  I think we can get this fixed back to showing only those 
skins available to the chosen language if any are available - otherwise 
we display the default language's skins.

Because we don't use javascript forms, the choices can get out of sync.

> Let me play with the site a bit so that I can get a better sense of these 
> things. So far, I think that the best solution is to just put an empty 
> directory in all the language directories with a skin.ini file pointing 
> couple of directories backward to whatever the "basic" directory is for a 
> given site.
> 

Might end up being the best way to provide the full translations and make 
all skins available.

Joe

> peace out!
> 
> 
> ----)(-----
> Luis Mondesi
> System Administrator/Web developer
> LatinoMixed.com
> 
> le...@ho...
> 
> "Black holes are where God divided by zero" - Steven Wright
> 
> Public signature: http://www.latinomixed.com/lems1/public-a.asc
>