cctools-cchost

[Cctools-cchost] User language selection

[Marcus C. <ma...@br...>]

Hi,

I'm developing a music colloboration website for european students=20
called MODEM (don't ask :=ACo)

I've reskinned (kind of) my cchost install at:
http://ccdev18.dreamhosters.com/

I need user switchable language for my project. I've seen that this is=20
in development and I'd like to help.

I've enabled italian language support.

With en_US set as default, I then tried switching the admin user=20
language to Italian (the only option I've given the site).

Everything is in English.

So I login as a test user, switch the profile to Italian - nothing doing.

With both users profiles set to default lang I switch the site to Italian=
.

The main page content is now in italian (with some omissions which I'm=20
guessing are missing in the locale files).
However the sidebar links are still english.

When i switch admins profile to Italian, the sidebar becomes Italian.

I log in as the test user whose profile is set to default, everything is=20
in Italian (including the sidebar).
Set the test user profile to English, everything is Italian still.

My test user:
test_user
password:
sesame

cchost version 3.2SVN

I expect I need to upgrade, but I wanted to check the stability of the=20
current SVN version as I need to demo this at least mostly working quite=20
soon.

TIA

Marcus Clements

BTW sorry about the auto-responder when I went on holiday - didn't think=20
about the effect for the the list.

Re: [Cctools-cchost] User language selection

[Victor S. <fou...@gm...>]

On 1/19/07, Marcus Clements <ma...@br...> wrote:
> With en_US set as default, I then tried switching the admin user
> language to Italian (the only option I've given the site).

If you're talking about the "Allow User to Set Language" (per-user
language) feature then we had to disable that in the sources because
it was causing configurations to be wiped out. The bug that was
causing that has since been fixed, but the fix has not been tested
(which means there is probably another bug waiting to happen).

The code in question is in cclib/cc-language.php you want to enable
the code around line 136 (the Id field at the top of the file for mine
is 4467). The comment block above it says:

// The code is an example of how to do things once the
// user_language field is sure to work... (etc.)

line 135: remove "/*"
line 153: remove "*/"

If it works it's a miracle, if not, Jon (who wrote this code) or I
will take a stab at it.

Also, Jon can speak as to how complete the Italian translation is,
i.e. even if the code works, I have no idea how much of the site was
actually translated in the Italian PO.

VS

Re: [Cctools-cchost] User language selection

[Jon P. <jo...@cr...>]

On Fri, 2007-01-19 at 13:02 -0800, Victor Stone wrote:
> On 1/19/07, Marcus Clements <ma...@br...> wrote:
> > With en_US set as default, I then tried switching the admin user
> > language to Italian (the only option I've given the site).
> 
> If you're talking about the "Allow User to Set Language" (per-user
> language) feature then we had to disable that in the sources because
> it was causing configurations to be wiped out. The bug that was
> causing that has since been fixed, but the fix has not been tested
> (which means there is probably another bug waiting to happen).
> 
> The code in question is in cclib/cc-language.php you want to enable
> the code around line 136 (the Id field at the top of the file for mine
> is 4467). The comment block above it says:
> 
> // The code is an example of how to do things once the
> // user_language field is sure to work... (etc.)
> 
> line 135: remove "/*"
> line 153: remove "*/"
> 
> If it works it's a miracle, if not, Jon (who wrote this code) or I
> will take a stab at it.
> 
> Also, Jon can speak as to how complete the Italian translation is,
> i.e. even if the code works, I have no idea how much of the site was
> actually translated in the Italian PO.
> 
> VS

Yes, its somewhat complete, but I'd like to focuse from this WED until
next TUES, getting more translations done, etc.

Here is info on how to do:

http://wiki.creativecommons.org/Translator

Of course, you can submit the standard open source way, the language as
a patch to our patch tracker: http://sf.net/projects/cctools

Or, use the slightly out of date strings at
http://translate.creativecommons.org/ (I need to hack on this in the
future so we have an up-to-date version of strings)...

Jon

-- 
Jon Phillips
jo...@cr...
cell: 510.499.0894

Community Developer
Creative Commons
www.creativecommons.org

Re: [Cctools-cchost] User language selection

[Marcus C. <ma...@br...>]

Hi Victor,

I've had a good look around, enabled the debugger, poked a few things=20
and I'm slowly getting a clearer picture of how cchost works.

One thing I've noticed is that the menu doesn't get rebuilt from scratch=20
when the site language is changed. I expect an event needs to be raised=20
when the language changes to make this happen. I'll have a look at that=20
soon.

A good proportion of the site is translated into Italian. I'll arrange=20
the rest of it over the coming weeks, maybe by contacting the original=20
translator.

I'll continue to experiment with setting the user language in profiles=20
and see where I can break it and maybe fix it.

On the dreamhost dev site you gave me, can I have access to a MySQL=20
admin interface of some sort? My command line SQL isn't what it could be =
;=AC)

Anyway I know you're busy with the big rewrite so I'm not expecting=20
anything in the way of help. I'll keep the list up to date with my=20
progress anyhow.

One quick question - should I check out the code again now or wait a bit=20
until it stabilises?

cheers

Marcus


Victor Stone wrote:
> On 1/19/07, Marcus Clements <ma...@br...> wrote:
>> With en_US set as default, I then tried switching the admin user
>> language to Italian (the only option I've given the site).
>
> If you're talking about the "Allow User to Set Language" (per-user
> language) feature then we had to disable that in the sources because
> it was causing configurations to be wiped out. The bug that was
> causing that has since been fixed, but the fix has not been tested
> (which means there is probably another bug waiting to happen).
>
> The code in question is in cclib/cc-language.php you want to enable
> the code around line 136 (the Id field at the top of the file for mine
> is 4467). The comment block above it says:
>
> // The code is an example of how to do things once the
> // user_language field is sure to work... (etc.)
>
> line 135: remove "/*"
> line 153: remove "*/"
>
> If it works it's a miracle, if not, Jon (who wrote this code) or I
> will take a stab at it.
>
> Also, Jon can speak as to how complete the Italian translation is,
> i.e. even if the code works, I have no idea how much of the site was
> actually translated in the Italian PO.
>
> VS
>

--=20
Marcus Clements
Brightonart Ltd.
www.brightonart.org
+44 (0)7866 316498
+34 606 053 777

Re: [Cctools-cchost] User language selection

[Victor S. <fou...@gm...>]

On 1/23/07, Marcus Clements <ma...@br...> wrote:
>  One thing I've noticed is that the menu doesn't get rebuilt from scratch
> when the site language is changed. I expect an event needs to be raised w=
hen
> the language changes to make this happen. I'll have a look at that soon.

heh, yea, we tried that -- that's precisely why we had to recall 3.0
because that's exactly the code that blew away user's profile lol.

Meanwhile, we reworked things and (in the latest SVN builds anyway) I
added a whole bunch of code to merge ALL config string (menus, tabs,
all admin to user text, etc.) with the strings in the source code.

It's more than likely the Italian translators did their work before
the new language editor was implemented.

The exact steps for getting config string translated is a bit arcane
and quite frankly I've forgotten them now. Maybe Jon can write it all
up and I'll including that in the admin docs for 4.0

>
>  I'll continue to experiment with setting the user language in profiles a=
nd
> see where I can break it and maybe fix it.

wahoo (seriously thanks)

>
>  On the dreamhost dev site you gave me, can I have access to a MySQL admi=
n
> interface of some sort? My command line SQL isn't what it could be ;=AC)

There is a phpmyadmin but I'm not sure how to give you access to just
that install. I'm furiously preparing for a ccMixter contest that
start tomorrow/Wed morning (!!) and as soon as I finish doing that (or
pass out and wake up) I look into that.

ftyi, before (finally) installing phpmyadmin on the mixter server I
wrote braindead db dumper/editor that might be available to you now,
check out 'mixter db' under 'global setting'  -- if you see it.

>
>  One quick question - should I check out the code again now or wait a bit
> until it stabilises?

You should be able to refresh your ccdev site (that's the code running
on ccMixter), in fact, I kind of suggest you do (perhaps take a
snapshot of the tree first? gzip is your friend)

VS

Re: [Cctools-cchost] User language selection

[Jon P. <jo...@cr...>]

On Tue, 2007-01-23 at 01:47 -0800, Victor Stone wrote:
> On 1/23/07, Marcus Clements <ma...@br...> wrote:
> >  One thing I've noticed is that the menu doesn't get rebuilt from scrat=
ch
> > when the site language is changed. I expect an event needs to be raised=
 when
> > the language changes to make this happen. I'll have a look at that soon=
.
>=20
> heh, yea, we tried that -- that's precisely why we had to recall 3.0
> because that's exactly the code that blew away user's profile lol.
>=20
> Meanwhile, we reworked things and (in the latest SVN builds anyway) I
> added a whole bunch of code to merge ALL config string (menus, tabs,
> all admin to user text, etc.) with the strings in the source code.
>=20
> It's more than likely the Italian translators did their work before
> the new language editor was implemented.
>=20
> The exact steps for getting config string translated is a bit arcane
> and quite frankly I've forgotten them now. Maybe Jon can write it all
> up and I'll including that in the admin docs for 4.0

Yes, me too, but it is vital for 4.0. I will take this on for the
documentation...

> >
> >  I'll continue to experiment with setting the user language in profiles=
 and
> > see where I can break it and maybe fix it.
>=20
> wahoo (seriously thanks)

Yah, that would be excellent! I've gotten distracted majorly ;) Its
great you are helping out so it gets me back into :)

> >
> >  On the dreamhost dev site you gave me, can I have access to a MySQL ad=
min
> > interface of some sort? My command line SQL isn't what it could be ;=C2=
=AC)
>=20
> There is a phpmyadmin but I'm not sure how to give you access to just
> that install. I'm furiously preparing for a ccMixter contest that
> start tomorrow/Wed morning (!!) and as soon as I finish doing that (or
> pass out and wake up) I look into that.
>=20
> ftyi, before (finally) installing phpmyadmin on the mixter server I
> wrote braindead db dumper/editor that might be available to you now,
> check out 'mixter db' under 'global setting'  -- if you see it.
>=20
> >
> >  One quick question - should I check out the code again now or wait a b=
it
> > until it stabilises?
>=20
> You should be able to refresh your ccdev site (that's the code running
> on ccMixter), in fact, I kind of suggest you do (perhaps take a
> snapshot of the tree first? gzip is your friend)
>=20
> VS
>=20

Yeah, totally...I would do this before updating to the newest huge
changes that VS did. But, also, it would be great to test out your new
changes so we can see the shakedown...this is pretty important IMO.

Jon

--=20
Jon Phillips
jo...@cr...
cell: 510.499.0894

Community Developer
Creative Commons
www.creativecommons.org

Re: [Cctools-cchost] User language selection

[Marcus C. <ma...@br...>]

Hi,

Good timing! I just finished a load of meetings on this and another 
project and am now finally free to continue with some actual work.

Where I got to is here: (this is a diff of my working copy of cclib/ 
with revision 5135)
http://ccdev18.dreamhosters.com/dev/patch

But there's a lot of CCDebug lines in there just so I could work out how 
the devil it all worked.
I'm checking to see if the user lang matches the main lang and if not, 
iterating through the menu, calling _() (see diff extract below)

It's really incomplete (tabs not done etc...) so I'm happy to update to 
the new code base with all of Victors new stuff and make it happen 
there, then submit a patch if that sounds useful.

     function &_menu_data($force = false, $action = CC_MENU_DISPLAY )
     {
+				global $CC_GLOBALS;
+				//$force = true; //MC
+				CCDebug::Log("_menu_data called"); // MC
+				
         static $_menu_data;
         if( $force || !isset($_menu_data) )
         {
@@ -376,6 +382,7 @@
 
             if( empty($_menu_data['items']) )
             {
+							//CCDebug::Log("menu data empty"); // MC
                 //
                 // ::::: Weirdass side effect warning :::::
                 //
@@ -395,7 +402,34 @@
             if( !empty($links_menu) )
                 $_menu_data['items'] += $links_menu;
         }
-
+				// MC added
+				// if current lang != default lang - translate
+				$lang_obj = $CC_GLOBALS["language"];
+				CCDebug::Log("Lang = ".$CC_GLOBALS["lang"]);
+				CCDebug::Log("User Lang = ".$CC_GLOBALS["user_language"]);
+				CCDebug::Log("obj->GetLang = ".$lang_obj->GetLanguage());
+				
+				if ($CC_GLOBALS["lang"] != $CC_GLOBALS["user_language"]) {
+					$tree= "";
+					//array_tree($_menu_data, $tree);	
+					//CCDebug::Log("MENU DATA TREE:::\n".$tree);				
+					//CCDebug::Log("User Lang not the same as app lang so translate menu data");
+					//CCDebug::Log("no menudata items ".count($_menu_data['items']));
+					//translate the menu
+					
+						reset($_menu_data['items']);
+						while (list($key, $value) = each($_menu_data['items'])) {
+							//CCDebug::Log("Translating ".$_menu_data['items'][$key]['menu_text']);
+							$_menu_data['items'][$key]['menu_text'] = _($value['menu_text']);
+						}					
+						
+						reset($_menu_data['groups']);
+						while (list($key, $value) = each($_menu_data['groups'])) {
+							//CCDebug::Log("Translating ".$_menu_data['groups'][$key]['group_name']);
+							$_menu_data['groups'][$key]['group_name'] = _($value['group_name']);
+						}				
+				}
+				// MC /added
         return( $_menu_data );
     }




Jon Phillips wrote:
> On Tue, 2007-01-23 at 01:47 -0800, Victor Stone wrote:
>   
>> On 1/23/07, Marcus Clements <ma...@br...> wrote:
>>     
>>>  One thing I've noticed is that the menu doesn't get rebuilt from scratch
>>> when the site language is changed. I expect an event needs to be raised when
>>> the language changes to make this happen. I'll have a look at that soon.
>>>       
>> heh, yea, we tried that -- that's precisely why we had to recall 3.0
>> because that's exactly the code that blew away user's profile lol.
>>
>> Meanwhile, we reworked things and (in the latest SVN builds anyway) I
>> added a whole bunch of code to merge ALL config string (menus, tabs,
>> all admin to user text, etc.) with the strings in the source code.
>>
>> It's more than likely the Italian translators did their work before
>> the new language editor was implemented.
>>
>> The exact steps for getting config string translated is a bit arcane
>> and quite frankly I've forgotten them now. Maybe Jon can write it all
>> up and I'll including that in the admin docs for 4.0
>>     
>
> Yes, me too, but it is vital for 4.0. I will take this on for the
> documentation...
>
>   
>>>  I'll continue to experiment with setting the user language in profiles and
>>> see where I can break it and maybe fix it.
>>>       
>> wahoo (seriously thanks)
>>     
>
> Yah, that would be excellent! I've gotten distracted majorly ;) Its
> great you are helping out so it gets me back into :)
>
>   
>>>  On the dreamhost dev site you gave me, can I have access to a MySQL admin
>>> interface of some sort? My command line SQL isn't what it could be ;¬)
>>>       
>> There is a phpmyadmin but I'm not sure how to give you access to just
>> that install. I'm furiously preparing for a ccMixter contest that
>> start tomorrow/Wed morning (!!) and as soon as I finish doing that (or
>> pass out and wake up) I look into that.
>>
>> ftyi, before (finally) installing phpmyadmin on the mixter server I
>> wrote braindead db dumper/editor that might be available to you now,
>> check out 'mixter db' under 'global setting'  -- if you see it.
>>
>>     
>>>  One quick question - should I check out the code again now or wait a bit
>>> until it stabilises?
>>>       
>> You should be able to refresh your ccdev site (that's the code running
>> on ccMixter), in fact, I kind of suggest you do (perhaps take a
>> snapshot of the tree first? gzip is your friend)
>>
>> VS
>>
>>     
>
> Yeah, totally...I would do this before updating to the newest huge
> changes that VS did. But, also, it would be great to test out your new
> changes so we can see the shakedown...this is pretty important IMO.
>
> Jon
>
>   

-- 
Marcus Clements
Brightonart Ltd.
www.brightonart.org
+44 (0)7866 316498
+34 606 053 777

Re: [Cctools-cchost] User language selection

[Victor S. <fou...@gm...>]

On 2/13/07, Marcus Clements <ma...@br...> wrote:
>  Where I got to is here: (this is a diff of my working copy of cclib/ with
> revision 5135)
>  But there's a lot of CCDebug lines in there just so I could work out how
> the devil it all worked.
>  I'm checking to see if the user lang matches the main lang and if not,
> iterating through the menu, calling _() (see diff extract below)
>
>  It's really incomplete (tabs not done etc...) so I'm happy to update to the
> new code base with all of Victors new stuff and make it happen there, then
> submit a patch if that sounds useful.

I appreciate the approach but I thought we discussed another way...

we need to *remove* the _() wrappers around strings in the code that
are headed for config (like the menu builders, default nav tabs, etc.,
submit forms, etc.)

The call to _() is already done every time you extract a string from
config (search for "_(" in cc-config.php) so:

// English goes into config:
                $configs->SaveConfig( 'menu',   $_menu_data['items'],
'',  false);

//and then the next line is:
               $_menu_data['items'] = $configs->GetConfig('menu');

The current language will come out, I promise.

The problem is that when the build menu (nav, submit forms, etc)
happens and the current language isn't English you're storing a random
language in config (no offense intended). We need to
a) build and store English in the config (always!),
b) let the language editor pick up the strings from config for translation,
c) then let the _() buried in GetConfig() do it's magic.

Make sense?

The trick is to make *sure* that the strings are all in config before
the language editor is called up. For example, I think the submit
forms wait until they are needed before they generate the 'default'
forms.

So the tasks are:
a) remove all _() from strings to be stored in config
b) modify all revert-type code (like menus and submit forms) to save
then, immediately retrieve, the config items
c) make sure all 'default' config string are stuff into config on
install and not "lazy loaded"

how am I doing?

...and can we release 4.0 w/o this? save it for 4.1?

VS

Re: [Cctools-cchost] User language selection

[Marcus C. <ma...@br...>]

Hi Victor,

This all makes perfect sense.
So how about this:
I'll keep a local copy of my changes for reference, check-out the current
version, test my site with your new code, help with bugs if necessary,
then start working on this stuff for potential incorporation in a future
release.

cheers

Marcus

> On 2/13/07, Marcus Clements <ma...@br...> wrote:
>>  Where I got to is here: (this is a diff of my working copy of cclib/
>> with
>> revision 5135)
>>  But there's a lot of CCDebug lines in there just so I could work out
>> how
>> the devil it all worked.
>>  I'm checking to see if the user lang matches the main lang and if not,
>> iterating through the menu, calling _() (see diff extract below)
>>
>>  It's really incomplete (tabs not done etc...) so I'm happy to update to
>> the
>> new code base with all of Victors new stuff and make it happen there,
>> then
>> submit a patch if that sounds useful.
>
> I appreciate the approach but I thought we discussed another way...
>
> we need to *remove* the _() wrappers around strings in the code that
> are headed for config (like the menu builders, default nav tabs, etc.,
> submit forms, etc.)
>
> The call to _() is already done every time you extract a string from
> config (search for "_(" in cc-config.php) so:
>
> // English goes into config:
>                 $configs->SaveConfig( 'menu',   $_menu_data['items'],
> '',  false);
>
> //and then the next line is:
>                $_menu_data['items'] = $configs->GetConfig('menu');
>
> The current language will come out, I promise.
>
> The problem is that when the build menu (nav, submit forms, etc)
> happens and the current language isn't English you're storing a random
> language in config (no offense intended). We need to
> a) build and store English in the config (always!),
> b) let the language editor pick up the strings from config for
> translation,
> c) then let the _() buried in GetConfig() do it's magic.
>
> Make sense?
>
> The trick is to make *sure* that the strings are all in config before
> the language editor is called up. For example, I think the submit
> forms wait until they are needed before they generate the 'default'
> forms.
>
> So the tasks are:
> a) remove all _() from strings to be stored in config
> b) modify all revert-type code (like menus and submit forms) to save
> then, immediately retrieve, the config items
> c) make sure all 'default' config string are stuff into config on
> install and not "lazy loaded"
>
> how am I doing?
>
> ...and can we release 4.0 w/o this? save it for 4.1?
>
> VS
>
>

Re: [Cctools-cchost] User language selection

[Jon P. <jo...@cr...>]

On Tue, 2007-02-13 at 11:34 +0000, Marcus Clements wrote:
> Hi Victor,
> 
> This all makes perfect sense.
> So how about this:
> I'll keep a local copy of my changes for reference, check-out the current
> version, test my site with your new code, help with bugs if necessary,
> then start working on this stuff for potential incorporation in a future
> release.

That sounds good...first things first, we need to identify where in the
code this needs to be changed and change this. Is there a list of these
and/or quick way to find?

Jon

> cheers
> 
> Marcus
> 
> > On 2/13/07, Marcus Clements <ma...@br...> wrote:
> >>  Where I got to is here: (this is a diff of my working copy of cclib/
> >> with
> >> revision 5135)
> >>  But there's a lot of CCDebug lines in there just so I could work out
> >> how
> >> the devil it all worked.
> >>  I'm checking to see if the user lang matches the main lang and if not,
> >> iterating through the menu, calling _() (see diff extract below)
> >>
> >>  It's really incomplete (tabs not done etc...) so I'm happy to update to
> >> the
> >> new code base with all of Victors new stuff and make it happen there,
> >> then
> >> submit a patch if that sounds useful.
> >
> > I appreciate the approach but I thought we discussed another way...
> >
> > we need to *remove* the _() wrappers around strings in the code that
> > are headed for config (like the menu builders, default nav tabs, etc.,
> > submit forms, etc.)
> >
> > The call to _() is already done every time you extract a string from
> > config (search for "_(" in cc-config.php) so:
> >
> > // English goes into config:
> >                 $configs->SaveConfig( 'menu',   $_menu_data['items'],
> > '',  false);
> >
> > //and then the next line is:
> >                $_menu_data['items'] = $configs->GetConfig('menu');
> >
> > The current language will come out, I promise.
> >
> > The problem is that when the build menu (nav, submit forms, etc)
> > happens and the current language isn't English you're storing a random
> > language in config (no offense intended). We need to
> > a) build and store English in the config (always!),
> > b) let the language editor pick up the strings from config for
> > translation,
> > c) then let the _() buried in GetConfig() do it's magic.
> >
> > Make sense?
> >
> > The trick is to make *sure* that the strings are all in config before
> > the language editor is called up. For example, I think the submit
> > forms wait until they are needed before they generate the 'default'
> > forms.
> >
> > So the tasks are:
> > a) remove all _() from strings to be stored in config
> > b) modify all revert-type code (like menus and submit forms) to save
> > then, immediately retrieve, the config items
> > c) make sure all 'default' config string are stuff into config on
> > install and not "lazy loaded"
> >
> > how am I doing?
> >
> > ...and can we release 4.0 w/o this? save it for 4.1?
> >
> > VS
> >
> >
> 
> 
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Cctools-cchost mailing list
> Cct...@li...
> https://lists.sourceforge.net/lists/listinfo/cctools-cchost
-- 
Jon Phillips
jo...@cr...
cell: 510.499.0894

Community Developer
Creative Commons
www.creativecommons.org

Re: [Cctools-cchost] User language selection

[Marcus C. <ma...@br...>]

There's a problem with the system as described.

$hash is declared static, so the table is stored as a cache.
_hash() is called by _hash_to_string() and by _string_to_hash() but it 
is never called with $force=true so static $hash created the first time 
_hash() is called never gets refreshed.

Is the $hash static for performance reasons? If not, can we just make it 
a local variable (I think).

If so, maybe we need to pass down a variable to indicate translation is 
necessary eg.
function GetConfig($type,$scope = '', $doTranslate=false)
function _hash_to_string($type,$data, $doTranslate=false)
then call         $hash = $this->_hash($doTranslate);

However I'm now confused about the $scope parameter to GetConfig(). What 
are the different scopes for config for?

OR

declare a variable in the global array:
$CC_GLOBALS['user_language_changed']
set it true on Login, Log off, User language change in profile, Global 
lang change by admin
test for it in GetConfig (I spose)

OR

something else completely! :)

regards

Marcus

Marcus Clements wrote:
> Hi Victor,
>
> This all makes perfect sense.
> So how about this:
> I'll keep a local copy of my changes for reference, check-out the current
> version, test my site with your new code, help with bugs if necessary,
> then start working on this stuff for potential incorporation in a future
> release.
>
> cheers
>
> Marcus
>
>   
>> On 2/13/07, Marcus Clements <ma...@br...> wrote:
>>     
>>>  Where I got to is here: (this is a diff of my working copy of cclib/
>>> with
>>> revision 5135)
>>>  But there's a lot of CCDebug lines in there just so I could work out
>>> how
>>> the devil it all worked.
>>>  I'm checking to see if the user lang matches the main lang and if not,
>>> iterating through the menu, calling _() (see diff extract below)
>>>
>>>  It's really incomplete (tabs not done etc...) so I'm happy to update to
>>> the
>>> new code base with all of Victors new stuff and make it happen there,
>>> then
>>> submit a patch if that sounds useful.
>>>       
>> I appreciate the approach but I thought we discussed another way...
>>
>> we need to *remove* the _() wrappers around strings in the code that
>> are headed for config (like the menu builders, default nav tabs, etc.,
>> submit forms, etc.)
>>
>> The call to _() is already done every time you extract a string from
>> config (search for "_(" in cc-config.php) so:
>>
>> // English goes into config:
>>                 $configs->SaveConfig( 'menu',   $_menu_data['items'],
>> '',  false);
>>
>> //and then the next line is:
>>                $_menu_data['items'] = $configs->GetConfig('menu');
>>
>> The current language will come out, I promise.
>>
>> The problem is that when the build menu (nav, submit forms, etc)
>> happens and the current language isn't English you're storing a random
>> language in config (no offense intended). We need to
>> a) build and store English in the config (always!),
>> b) let the language editor pick up the strings from config for
>> translation,
>> c) then let the _() buried in GetConfig() do it's magic.
>>
>> Make sense?
>>
>> The trick is to make *sure* that the strings are all in config before
>> the language editor is called up. For example, I think the submit
>> forms wait until they are needed before they generate the 'default'
>> forms.
>>
>> So the tasks are:
>> a) remove all _() from strings to be stored in config
>> b) modify all revert-type code (like menus and submit forms) to save
>> then, immediately retrieve, the config items
>> c) make sure all 'default' config string are stuff into config on
>> install and not "lazy loaded"
>>
>> how am I doing?
>>
>> ...and can we release 4.0 w/o this? save it for 4.1?
>>
>> VS
>>
>>
>>     
>
>
>   

-- 
Marcus Clements
Brightonart Ltd.
www.brightonart.org
+44 (0)7866 316498
+34 606 053 777

Re: [Cctools-cchost] User language selection

[Victor S. <fou...@gm...>]

On 2/28/07, Marcus Clements <ma...@br...> wrote:
>  $hash is declared static, so the table is stored as a cache.
>  _hash() is called by _hash_to_string() and by _string_to_hash() but it is
> never called with $force=true so static $hash created the first time _hash()
> is called never gets refreshed.
>
>  Is the $hash static for performance reasons? If not, can we just make it a
> local variable (I think).

Can you describe a situation where this is causing an issue?

>
>  If so, maybe we need to pass down a variable to indicate translation is
> necessary eg.
>  function GetConfig($type,$scope = '', $doTranslate=false)

The translation happens on every string in the TranslationMap every
time it comes out of config. If we're missing a string we need to add
it to the Map.

>
>  However I'm now confused about the $scope parameter to GetConfig(). What
> are the different scopes for config for?

'scope' means 'virtual root' -- allows for a different mini-sites with
different look/feel to exists on the same ccHost installation.

VS

Re: [Cctools-cchost] User language selection

[Marcus C. <ma...@br...>]

Victor Stone wrote:
> On 2/28/07, Marcus Clements <ma...@br...> wrote:
>>  $hash is declared static, so the table is stored as a cache.
>>  _hash() is called by _hash_to_string() and by _string_to_hash() but 
>> it is
>> never called with $force=true so static $hash created the first time 
>> _hash()
>> is called never gets refreshed.
>>
>>  Is the $hash static for performance reasons? If not, can we just 
>> make it a
>> local variable (I think).
>
> Can you describe a situation where this is causing an issue?
If $hash in _hash() in cc-config.php is left as a static then:

The site langauge is English.
I browse around as a user with user_langauge english, all fine.
I log in as a user with user language Italian, the menus and tabs are in 
English, but other text is in Italian.

If I force _hash() to rebuild each call using force=true
All the menus and tabs (well the ones with translation strings...) are 
in Italian, as is all the other text.

I'd like to more clearly understand the usage of the config array. 
Please correct:
The data is stored in the database. GetConfig() constructs the config 
array from this data and caches it as a hash in the static _cache 
property of the CCConfigs object. To make this hash it calls the _hash() 
method. However the _hash() method also has a static variable storing 
the hash. This is checked on entry and if not empty returned by the 
function, *unless* called with force=true... which never happens.

Sorry if this is all wrong, it's bending my head a little :)

>
>>
>>  If so, maybe we need to pass down a variable to indicate translation is
>> necessary eg.
>>  function GetConfig($type,$scope = '', $doTranslate=false)
>
> The translation happens on every string in the TranslationMap every
> time it comes out of config. If we're missing a string we need to add
> it to the Map.
Ah yes I was going to ask about the map next.
>
>>
>>  However I'm now confused about the $scope parameter to GetConfig(). 
>> What
>> are the different scopes for config for?
>
> 'scope' means 'virtual root' -- allows for a different mini-sites with
> different look/feel to exists on the same ccHost installation.
Ah right thanks.
>
> VS
>

-- 
Marcus Clements
Brightonart Ltd.
www.brightonart.org
+44 (0)7866 316498
+34 606 053 777

Re: [Cctools-cchost] User language selection

[Marcus C. <ma...@br...>]

Victor Stone wrote:
> On 3/1/07, Marcus Clements <ma...@br...> wrote:
>> > Can you describe a situation where this is causing an issue?
>> If $hash in _hash() in cc-config.php is left as a static then:
>>
>> The site langauge is English.
>> I browse around as a user with user_langauge english, all fine.
>> I log in as a user with user language Italian, the menus and tabs are in
>> English, but other text is in Italian.
>>
>> If I force _hash() to rebuild each call using force=true
>> All the menus and tabs (well the ones with translation strings...) are
>> in Italian, as is all the other text.
>
> OK, I haven't confirmed this but I'm pretty sure that the _() in
> _hash() is done before the user language has been set which is where
> the problem really is (I think you tried to tell me this in the last
> email but I didn't quite understand). That means we have to initialize
> the language before the hash is built, but the language module
> requires the config to be initialized... I believe thats what the
> Italians call 'catch-22'. We'll figure something out...
>
>
>> > The translation happens on every string in the TranslationMap every
>> > time it comes out of config. If we're missing a string we need to add
>> > it to the Map.
>> Ah yes I was going to ask about the map next.
>
> The map is needed because it would be disaster to translate
> non-user-interface strings.
>
> VS
>

-- 
Marcus Clements
Brightonart Ltd.
www.brightonart.org
+44 (0)7866 316498
+34 606 053 777

Re: [Cctools-cchost] User language selection

[Marcus C. <ma...@br...>]

Hi,

Further investigations into language support; I'm making notes here as I=20
go to understand the process:



CC_EVENT_TRANSLATE is invoked when a user changes language, and was
commented out when admins change language, so I'm taking this as a stub
for additional work...

When CCMenu::KillCache is called the menu is not fully rebuilt.
CCMenu::reset() calls _menu_data(true) but in the implementation of
_menu_data:

configs =3D& CCConfigs::GetTable();
            $_menu_data['items']  =3D $configs->GetConfig('menu');
            $_menu_data['groups'] =3D $configs->GetConfig('groups');

            if( empty($_menu_data['items']) )

This is only true when the menus are reverted to the originals and the
menu is fully rebuilt in the config array.

So the translation file contains translations for the standard menu
items and these are applied during the initial menu build (or when it's
reverted to the original). So we could translate the existing config
menu data each time the language is changed by the admin, but this would
apply a global language change, for users as well. The main text for
other pages is presumably built (and translated) each time it's it, or
maybe cached and the cache invalidated when the admin changes language
somewhere. More investigation needed...

Now I'm guessing what's needed is a config array *per required language*
for menu items. This shouldn't be restricted to two obviously. I guess
each menu items for each language could be built when first requested by
a user. Maybe a function to cache translations for all available
language avalable to admins. I'm not sure what the policy is on this
sort of thing.

I hope you guys don't mind me posting this stuff - let me know if I'm
barking up the wrong trees completely.

regards

Marcus





Marcus Clements wrote:
> Hi Victor,
>
> I've had a good look around, enabled the debugger, poked a few things=20
> and I'm slowly getting a clearer picture of how cchost works.
>
> One thing I've noticed is that the menu doesn't get rebuilt from=20
> scratch when the site language is changed. I expect an event needs to=20
> be raised when the language changes to make this happen. I'll have a=20
> look at that soon.
>
> A good proportion of the site is translated into Italian. I'll arrange=20
> the rest of it over the coming weeks, maybe by contacting the original=20
> translator.
>
> I'll continue to experiment with setting the user language in profiles=20
> and see where I can break it and maybe fix it.
>
> On the dreamhost dev site you gave me, can I have access to a MySQL=20
> admin interface of some sort? My command line SQL isn't what it could=20
> be ;=AC)
>
> Anyway I know you're busy with the big rewrite so I'm not expecting=20
> anything in the way of help. I'll keep the list up to date with my=20
> progress anyhow.
>
> One quick question - should I check out the code again now or wait a=20
> bit until it stabilises?
>
> cheers
>
> Marcus
>
>
> Victor Stone wrote:
>> On 1/19/07, Marcus Clements <ma...@br...> wrote:
>>> With en_US set as default, I then tried switching the admin user
>>> language to Italian (the only option I've given the site).
>>
>> If you're talking about the "Allow User to Set Language" (per-user
>> language) feature then we had to disable that in the sources because
>> it was causing configurations to be wiped out. The bug that was
>> causing that has since been fixed, but the fix has not been tested
>> (which means there is probably another bug waiting to happen).
>>
>> The code in question is in cclib/cc-language.php you want to enable
>> the code around line 136 (the Id field at the top of the file for mine
>> is 4467). The comment block above it says:
>>
>> // The code is an example of how to do things once the
>> // user_language field is sure to work... (etc.)
>>
>> line 135: remove "/*"
>> line 153: remove "*/"
>>
>> If it works it's a miracle, if not, Jon (who wrote this code) or I
>> will take a stab at it.
>>
>> Also, Jon can speak as to how complete the Italian translation is,
>> i.e. even if the code works, I have no idea how much of the site was
>> actually translated in the Italian PO.
>>
>> VS
>>
>
> --=20
> Marcus Clements
> Brightonart Ltd.
> www.brightonart.org
> +44 (0)7866 316498
> +34 606 053 777
> -----------------------------------------------------------------------=
-
>
> -----------------------------------------------------------------------=
--
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share=
your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
> -----------------------------------------------------------------------=
-
>
> _______________________________________________
> Cctools-cchost mailing list
> Cct...@li...
> https://lists.sourceforge.net/lists/listinfo/cctools-cchost
>  =20

--=20
Marcus Clements
Brightonart Ltd.
www.brightonart.org
+44 (0)7866 316498
+34 606 053 777

Re: [Cctools-cchost] User language selection

[Victor S. <fou...@gm...>]

ok, my fault for trying to do several things at the same time,
especially comment on code I'm not looking at.

On 1/23/07, Marcus Clements <ma...@br...> wrote:
> CC_EVENT_TRANSLATE is invoked when a user changes language, and was
> commented out when admins change language, so I'm taking this as a stub
> for additional work...

this event is deprecated, it's invoked but nobody listens (it's the
listening code that I nuked)

> When CCMenu::KillCache is called the menu is not fully rebuilt.
> CCMenu::reset() calls _menu_data(true) but in the implementation of
> _menu_data:
>
> configs =& CCConfigs::GetTable();
>             $_menu_data['items']  = $configs->GetConfig('menu');
>             $_menu_data['groups'] = $configs->GetConfig('groups');
>
>             if( empty($_menu_data['items']) )
>
> This is only true when the menus are reverted to the originals and the
> menu is fully rebuilt in the config array.

This is correct, otherwise all customizations would be lost everytime
things were refreshed. (my previous comment was reatled to a bug I
fixed in the KillCache method having to do with the URL map not being
properly flushed, not the menu)

>
> So the translation file contains translations for the standard menu
> items and these are applied during the initial menu build (or when it's
> reverted to the original). So we could translate the existing config
> menu data each time the language is changed by the admin, but this would
> apply a global language change, for users as well. The main text for
> other pages is presumably built (and translated) each time it's it, or
> maybe cached and the cache invalidated when the admin changes language
> somewhere. More investigation needed...

Merely having a new menu for every language is not enough, there are
dozens and dozens of strings saved in the config (nav tabs, submit
forms, ban messages, and all other dynamic user seen strings). So it
was decided to extract all these strings while editing languages, then
merged with the standard strings to make the PO that gets loaded. All
config strings are tranlated from English to the current language in
cc-config.php (the central extraction point for all strings during
page building)

Here's how I understand it works based on using the language editor
(Jon *please* confirm)

1. You edit the site, the *whole* site the way you want to look and
feel in English, Create vroots, nav tabs, submit forms, menu, etc.
etc.

2. Your translator uses /media/admin/terms to edit/create a string
file with all the code and config strings merged together.

3. Your translator then clicks on the 'Create PO' button

4. Some magic happens here that I don't know that creates the MO file
under /locale/default/it/...

Hope that clears things up...

VS

Re: [Cctools-cchost] User language selection

[Victor S. <fou...@gm...>]

(oh, I should mention that once in the language editor you can quickly
see what strings need editing by the asterisk at the beginning of the
source line)

VS

Re: [Cctools-cchost] User language selection

[Marcus C. <ma...@br...>]

That's great.
I'll make a list at some point of any important messages missing.
Nice work!

regards

Marcus


Gian Maria Di Flumeri wrote:
> About the italian translation..,
> I quit translating because  I was not able to understand where to
> translate and when (I'm not a programmer) and how to keep my pot file
> updated.. But if you make it easy for me, I'm glad to help..
>
> Gianmaria
>
> On 1/23/07, Marcus Clements <ma...@br...> wrote:
>>
>>  Hi Victor,
>>
>>  I've had a good look around, enabled the debugger, poked a few=20
>> things and
>> I'm slowly getting a clearer picture of how cchost works.
>>
>>  One thing I've noticed is that the menu doesn't get rebuilt from=20
>> scratch
>> when the site language is changed. I expect an event needs to be=20
>> raised when
>> the language changes to make this happen. I'll have a look at that soo=
n.
>>
>>  A good proportion of the site is translated into Italian. I'll=20
>> arrange the
>> rest of it over the coming weeks, maybe by contacting the original
>> translator.
>>
>>  I'll continue to experiment with setting the user language in=20
>> profiles and
>> see where I can break it and maybe fix it.
>>
>>  On the dreamhost dev site you gave me, can I have access to a MySQL=20
>> admin
>> interface of some sort? My command line SQL isn't what it could be ;=AC=
)
>>
>>  Anyway I know you're busy with the big rewrite so I'm not expecting
>> anything in the way of help. I'll keep the list up to date with my=20
>> progress
>> anyhow.
>>
>>  One quick question - should I check out the code again now or wait a=20
>> bit
>> until it stabilises?
>>
>>  cheers
>>
>>  Marcus
>>
>>
>>  Victor Stone wrote:
>> On 1/19/07, Marcus Clements <ma...@br...> wrote:
>>
>> With en_US set as default, I then tried switching the admin user
>>  language to Italian (the only option I've given the site).
>>
>>  If you're talking about the "Allow User to Set Language" (per-user
>>  language) feature then we had to disable that in the sources because
>>  it was causing configurations to be wiped out. The bug that was
>>  causing that has since been fixed, but the fix has not been tested
>>  (which means there is probably another bug waiting to happen).
>>
>>  The code in question is in cclib/cc-language.php you want to enable
>>  the code around line 136 (the Id field at the top of the file for min=
e
>>  is 4467). The comment block above it says:
>>
>>  // The code is an example of how to do things once the
>>  // user_language field is sure to work... (etc.)
>>
>>  line 135: remove "/*"
>>  line 153: remove "*/"
>>
>>  If it works it's a miracle, if not, Jon (who wrote this code) or I
>>  will take a stab at it.
>>
>>  Also, Jon can speak as to how complete the Italian translation is,
>>  i.e. even if the code works, I have no idea how much of the site was
>>  actually translated in the Italian PO.
>>
>>  VS
>>
>>
>>  --
>> Marcus Clements
>> Brightonart Ltd.
>> www.brightonart.org
>> +44 (0)7866 316498
>> +34 606 053 777
>>
>> ----------------------------------------------------------------------=
---=20
>>
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to=20
>> share your
>> opinions on IT & business topics through brief surveys - and earn cash
>> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=
=3DDEVDEV=20
>>
>>
>> _______________________________________________
>> Cctools-cchost mailing list
>> Cct...@li...
>> https://lists.sourceforge.net/lists/listinfo/cctools-cchost
>>
>>
>>
>

--=20
Marcus Clements
Brightonart Ltd.
www.brightonart.org
+44 (0)7866 316498
+34 606 053 777

Re: [Cctools-cchost] User language selection

[Victor S. <fou...@gm...>]

On 1/23/07, Marcus Clements <ma...@br...> wrote:
> CC_EVENT_TRANSLATE is invoked when a user changes language, and was
> commented out when admins change language, so I'm taking this as a stub
> for additional work...

you should take it for killed code, I think that's gone in later versions (?)

> When CCMenu::KillCache is called the menu is not fully rebuilt.
> CCMenu::reset() calls _menu_data(true) but in the implementation of
> _menu_data:

again, I think that's been fixed (unfortunately I don't have code in
front of me) are you sure you're looking at the latest builds?

> More investigation needed...

Jon, do you remember the exact steps we worked out here?

> Now I'm guessing what's needed is a config array *per required language*
> for menu items. This shouldn't be restricted to two obviously.

There's code in the latest cc-config.php that calls _() on each string
as it comes out of the config database so we don't need per-lang
config string in the db, just in the PO files.

> I hope you guys don't mind me posting this stuff - let me know if I'm
> barking up the wrong trees completely.

Not at all, just need to figure out if you're up to date or not...

VS

Re: [Cctools-cchost] User language selection

[Marcus C. (lists) <ma...@br...>]

Ok maybe I'm missing something in subversion.
I'm familiar with CVS but not svn - until now...

I did sh up this morning:
Updated to revision 5128

svn status output:

?      up
?      dev18-files
?      core
?      dev18-lib
?      logs
?      dev18-templates
!      ccadmin
?      locale/modem_locale
?      cctemplates/sidebar.xml
M      index.php
M      cclib/cc-language.php
?      cclib/phptal/phptal_cache/_ccc_.txt
M      cclib/cc-menu.php

after running svn diff on the modified files:

The three modified files contain CCDebug::Log lines that I added to 
fathom things out plus the beginnings of the CC_EVENT_TRANSLATE handler 
in cc-language.php

I've also had a browse round the svn web interface.
cc-language.php hasn't been touched for three months...
http://cctools.svn.sourceforge.net/viewvc/cctools/cchost/trunk/cclib/cc-language.php?revision=4467&view=markup

just realised my previous posts had phone numbers on (doh!) so i'll look 
forward to some wonderful folk calling with great new offers soon! :o(

regards

Marcus

Victor Stone wrote:
> On 1/23/07, Marcus Clements <ma...@br...> wrote:
>> CC_EVENT_TRANSLATE is invoked when a user changes language, and was
>> commented out when admins change language, so I'm taking this as a stub
>> for additional work...
>
> you should take it for killed code, I think that's gone in later 
> versions (?)
>
>> When CCMenu::KillCache is called the menu is not fully rebuilt.
>> CCMenu::reset() calls _menu_data(true) but in the implementation of
>> _menu_data:
>
> again, I think that's been fixed (unfortunately I don't have code in
> front of me) are you sure you're looking at the latest builds?
>
>> More investigation needed...
>
> Jon, do you remember the exact steps we worked out here?
>
>> Now I'm guessing what's needed is a config array *per required language*
>> for menu items. This shouldn't be restricted to two obviously.
>
> There's code in the latest cc-config.php that calls _() on each string
> as it comes out of the config database so we don't need per-lang
> config string in the db, just in the PO files.
>
>> I hope you guys don't mind me posting this stuff - let me know if I'm
>> barking up the wrong trees completely.
>
> Not at all, just need to figure out if you're up to date or not...
>
> VS
>

Re: [Cctools-cchost] User language selection

[Marcus C. <ma...@br...>]

The adventure continues. I'd forgotten how difficult it is to get to 
grips with a large existing codebase, even when it is well written!
I've sprayed CCDebug::Log messages all over the code.
Thanks for the MyAdmin, it helps a lot. I'm no good with black boxes - 
always want to take the lid off and poke around.

The good news is that by dirty hacking I've got a cchost that allows the 
user to change the language and displays the page accordingly (well most 
of the page :).
It doesn't seem to lose users or do anything particularly bad so far.


I'm translating the menu_text in a hack in  _menu_data()  [line 370 
cc-menu.php] by iterating through the array and calling _()
I need to do this for the menu groups, the navigator tabs and probably 
some other places.
Maybe you could suggest where?

I have noticed that CCLogin::InitCurrentUser() is called directly from 
index.html, and then again as there is an event handler for 
CC_EVENT_APP_INIT in the top of cc-login.php. I'm not sure why it 
happens twice...

Next:
menu groups
navigator tabs

regards

Marcus


Victor Stone wrote:
> On 1/25/07, Marcus Clements <ma...@br...> wrote:
>> Currently, after changing default lang, when the menu is reverted to the
>> parent the config data gets rebuilt in the new language, right?
>> This is a problem for sites with more than two langs as if the default
>> is Italian and the user sets French we would have to reverse translate
>> to English and then to French. Ugh.
>
> Quite frankly this is a freakin AMAZING catch.
>
> There's about 6 places in the code (the onBuildMenu handlers) that
> should NOT be wrapped in _() because you're absolutely right, these
> need to be in English. The same goes for revert submit forms,
> generating default nav tabs, etc. Basically any string in code that is
> stored in config should never be translated by code and leave it for
> the gui editor/merger.
>
> Color me impressed.
>
> Unfortunately, it would kill me to try to get this in before I do my
> *large* checkin but it will go then (or shortly after)
>
> VS
>

-- 
Marcus Clements
Brightonart Ltd.
www.brightonart.org
+44 (0)7866 316498
+34 606 053 777

Re: [Cctools-cchost] User language selection

[Marcus C. <ma...@br...>]

Groups and menus translating now.

For some reason the menu is not being translated on the profile page 
loaded after login.
Maybe it's cached...

Marcus Clements wrote:
> The adventure continues. I'd forgotten how difficult it is to get to 
> grips with a large existing codebase, even when it is well written!
> I've sprayed CCDebug::Log messages all over the code.
> Thanks for the MyAdmin, it helps a lot. I'm no good with black boxes - 
> always want to take the lid off and poke around.
>
> The good news is that by dirty hacking I've got a cchost that allows 
> the user to change the language and displays the page accordingly 
> (well most of the page :).
> It doesn't seem to lose users or do anything particularly bad so far.
>
>
> I'm translating the menu_text in a hack in  _menu_data()  [line 370 
> cc-menu.php] by iterating through the array and calling _()
> I need to do this for the menu groups, the navigator tabs and probably 
> some other places.
> Maybe you could suggest where?
>
> I have noticed that CCLogin::InitCurrentUser() is called directly from 
> index.html, and then again as there is an event handler for 
> CC_EVENT_APP_INIT in the top of cc-login.php. I'm not sure why it 
> happens twice...
>
> Next:
> menu groups
> navigator tabs
>
> regards
>
> Marcus
>
>
> Victor Stone wrote:
>> On 1/25/07, Marcus Clements <ma...@br...> wrote:
>>> Currently, after changing default lang, when the menu is reverted to 
>>> the
>>> parent the config data gets rebuilt in the new language, right?
>>> This is a problem for sites with more than two langs as if the default
>>> is Italian and the user sets French we would have to reverse translate
>>> to English and then to French. Ugh.
>>
>> Quite frankly this is a freakin AMAZING catch.
>>
>> There's about 6 places in the code (the onBuildMenu handlers) that
>> should NOT be wrapped in _() because you're absolutely right, these
>> need to be in English. The same goes for revert submit forms,
>> generating default nav tabs, etc. Basically any string in code that is
>> stored in config should never be translated by code and leave it for
>> the gui editor/merger.
>>
>> Color me impressed.
>>
>> Unfortunately, it would kill me to try to get this in before I do my
>> *large* checkin but it will go then (or shortly after)
>>
>> VS
>>
>
> -- 
> Marcus Clements
> Brightonart Ltd.
> www.brightonart.org
> +44 (0)7866 316498
> +34 606 053 777
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> ------------------------------------------------------------------------
>
> _______________________________________________
> Cctools-cchost mailing list
> Cct...@li...
> https://lists.sourceforge.net/lists/listinfo/cctools-cchost
>   

-- 
Marcus Clements
Brightonart Ltd.
www.brightonart.org
+44 (0)7866 316498
+34 606 053 777

Re: [Cctools-cchost] User language selection

[Jon P. <jo...@cr...>]

On Thu, 2007-01-25 at 17:27 +0100, Marcus Clements wrote:
> The adventure continues. I'd forgotten how difficult it is to get to
> grips with a large existing codebase, even when it is well written!
> I've sprayed CCDebug::Log messages all over the code.
> Thanks for the MyAdmin, it helps a lot. I'm no good with black boxes -
> always want to take the lid off and poke around.
> 
> The good news is that by dirty hacking I've got a cchost that allows
> the user to change the language and displays the page accordingly
> (well most of the page :).
> It doesn't seem to lose users or do anything particularly bad so far.
> 

Cool, how dirty ;) Like break pre-existing dirty? ;)

> I'm translating the menu_text in a hack in  _menu_data()  [line 370
> cc-menu.php] by iterating through the array and calling _()
> I need to do this for the menu groups, the navigator tabs and probably
> some other places.
> Maybe you could suggest where?

Can show (code) how you are doing this?

> I have noticed that CCLogin::InitCurrentUser() is called directly from
> index.html, and then again as there is an event handler for
> CC_EVENT_APP_INIT in the top of cc-login.php. I'm not sure why it
> happens twice...
> 
> Next:
> menu groups
> navigator tabs

Cool, where are you at now?

> regards
> 
> Marcus

Hi Marcus, this all sounds interesting. I'm curious if you have tried to
merge your changes with current ccHost in SVN? This would be great to
get as a patch to our patch tracker so we can test out. We are trying to
lock a release down for next week, with a soft freeze on WED of this
week.

I'm apologize for not getting to this in time, but your changes would be
great to get into 4.0 if you can merge then in time, and then make a
patch for them...

Jon

> 
> Victor Stone wrote: 
> > On 1/25/07, Marcus Clements <ma...@br...> wrote: 
> > > Currently, after changing default lang, when the menu is reverted
> > > to the 
> > > parent the config data gets rebuilt in the new language, right? 
> > > This is a problem for sites with more than two langs as if the
> > > default 
> > > is Italian and the user sets French we would have to reverse
> > > translate 
> > > to English and then to French. Ugh. 
> > 
> > Quite frankly this is a freakin AMAZING catch. 
> > 
> > There's about 6 places in the code (the onBuildMenu handlers) that 
> > should NOT be wrapped in _() because you're absolutely right, these 
> > need to be in English. The same goes for revert submit forms, 
> > generating default nav tabs, etc. Basically any string in code that
> > is 
> > stored in config should never be translated by code and leave it
> > for 
> > the gui editor/merger. 
> > 
> > Color me impressed. 
> > 
> > Unfortunately, it would kill me to try to get this in before I do
> > my 
> > *large* checkin but it will go then (or shortly after) 
> > 
> > VS 
> > 
> 
> -- 
> Marcus Clements
> Brightonart Ltd.
> www.brightonart.org
> +44 (0)7866 316498
> +34 606 053 777
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________ Cctools-cchost mailing list Cct...@li... https://lists.sourceforge.net/lists/listinfo/cctools-cchost
-- 
Jon Phillips
jo...@cr...
cell: 510.499.0894

Community Developer
Creative Commons
www.creativecommons.org

Re: [Cctools-cchost] User language selection

[Jon P. <jo...@cr...>]

On Tue, 2007-02-13 at 11:34 +0000, Marcus Clements wrote:
> Hi Victor,
> 
> This all makes perfect sense.
> So how about this:
> I'll keep a local copy of my changes for reference, check-out the current
> version, test my site with your new code, help with bugs if necessary,
> then start working on this stuff for potential incorporation in a future
> release.
> 
> cheers
> 
> Marcus

The other things is that it would be good for you to send in some
smaller patch so we can empower you to commit more. This would be better
than one big patch.

Please check out the latest from SVN (http://sf.net/projects/cctools)
and apply your changes and send in one or two smaller patches towards
the final goal.

Then, we can review, apply and hopefully give you SVN access to directly
help us with this task.

Unfortunately, I think we should wait for more aggressive changes until
Monday/Tuesday when our development on trunk unfreezes for this type of
work. There will more than likely be some code changes as well for
multi-byte characters...just wanting to get 4.0 solid, but will prolly
have to launch a 4.1 soon thereafter with these language fixes...

Jon

> > On 2/13/07, Marcus Clements <ma...@br...> wrote:
> >>  Where I got to is here: (this is a diff of my working copy of cclib/
> >> with
> >> revision 5135)
> >>  But there's a lot of CCDebug lines in there just so I could work out
> >> how
> >> the devil it all worked.
> >>  I'm checking to see if the user lang matches the main lang and if not,
> >> iterating through the menu, calling _() (see diff extract below)
> >>
> >>  It's really incomplete (tabs not done etc...) so I'm happy to update to
> >> the
> >> new code base with all of Victors new stuff and make it happen there,
> >> then
> >> submit a patch if that sounds useful.
> >
> > I appreciate the approach but I thought we discussed another way...
> >
> > we need to *remove* the _() wrappers around strings in the code that
> > are headed for config (like the menu builders, default nav tabs, etc.,
> > submit forms, etc.)
> >
> > The call to _() is already done every time you extract a string from
> > config (search for "_(" in cc-config.php) so:
> >
> > // English goes into config:
> >                 $configs->SaveConfig( 'menu',   $_menu_data['items'],
> > '',  false);
> >
> > //and then the next line is:
> >                $_menu_data['items'] = $configs->GetConfig('menu');
> >
> > The current language will come out, I promise.
> >
> > The problem is that when the build menu (nav, submit forms, etc)
> > happens and the current language isn't English you're storing a random
> > language in config (no offense intended). We need to
> > a) build and store English in the config (always!),
> > b) let the language editor pick up the strings from config for
> > translation,
> > c) then let the _() buried in GetConfig() do it's magic.
> >
> > Make sense?
> >
> > The trick is to make *sure* that the strings are all in config before
> > the language editor is called up. For example, I think the submit
> > forms wait until they are needed before they generate the 'default'
> > forms.
> >
> > So the tasks are:
> > a) remove all _() from strings to be stored in config
> > b) modify all revert-type code (like menus and submit forms) to save
> > then, immediately retrieve, the config items
> > c) make sure all 'default' config string are stuff into config on
> > install and not "lazy loaded"
> >
> > how am I doing?
> >
> > ...and can we release 4.0 w/o this? save it for 4.1?
> >
> > VS
> >
> >
> 
-- 
Jon Phillips
jo...@cr...
cell: 510.499.0894

Community Developer
Creative Commons
www.creativecommons.org

Re: [Cctools-cchost] User language selection

[Victor S. <fou...@gm...>]

On 2/13/07, Jon Phillips <jo...@cr...> wrote:
> On Tue, 2007-02-13 at 11:34 +0000, Marcus Clements wrote:
> > I'll keep a local copy of my changes for reference, check-out the current
> > version, test my site with your new code, help with bugs if necessary,

yes, it is necessary ;) your type of site is the most "at risk" so
it's important to know that I haven't messed it up.

> > then start working on this stuff for potential incorporation in a future
> > release.

>Jon:
> work. There will more than likely be some code changes as well for
> multi-byte characters...just wanting to get 4.0 solid, but will prolly
> have to launch a 4.1 soon thereafter with these language fixes...

yup, to be clear: we're doing a psuedo RC using 3x builds tomorrow,
then aiming for official 4.0 release a week from tomorrow.

>we need to identify where in the
>code this needs to be changed and change this. Is there a list of these
>and/or quick way to find?

The config code keeps a map of which strings need to be translated
(otherwise internal code-dependent strings like tags, etc. would get
translated). The map itself can be found at

cclib/cc-config.php
function SaveDefaultCfgStringMap()

a quick search of the keys in that array should get all the cases.

For 4.1 ;)

VS