You can subscribe to this list here.
2008 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2009 |
Jan
(1) |
Feb
|
Mar
|
Apr
(4) |
May
(3) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2010 |
Jan
|
Feb
|
Mar
|
Apr
(6) |
May
(10) |
Jun
(1) |
Jul
(3) |
Aug
(19) |
Sep
(52) |
Oct
(5) |
Nov
(15) |
Dec
|
2011 |
Jan
|
Feb
(65) |
Mar
(53) |
Apr
(55) |
May
(37) |
Jun
|
Jul
(1) |
Aug
(17) |
Sep
(28) |
Oct
(7) |
Nov
|
Dec
|
2012 |
Jan
(3) |
Feb
|
Mar
(2) |
Apr
|
May
(4) |
Jun
(3) |
Jul
(1) |
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
(1) |
2013 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
2014 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
From: Mark W. <ma...@rw...> - 2011-03-05 02:53:43
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Hi Scott, <br> <br> I had a quick look and I committed back about three lines of changes to test-language-stuff.php.<br> <br> As long as you dont append .php to the page url , everything loads through the main site and the print_r stuff now prints out so that it is readable in a browser. :)<br> <br> How does one set the language to use?<br> <br> Mark<br> <pre class="moz-signature" cols="72">_____________________________________________ Mob: 07725 695178 Email: <a class="moz-txt-link-abbreviated" href="mailto:ma...@rw...">ma...@rw...</a></pre> <br> On 04/03/2011 22:25, Scott Miller wrote: <blockquote cite="mid:AAN...@ma..." type="cite">Hi guys,<br> <br> I just checked in the minimal amount of code I've sucked in from joomla to get the language stuff to work, and a test script that demonstrates how to load the classes and get the language files loaded. Currently the script just spits out a print_r of a couple classes and some debugging output. So, it's not sexy and pretty yet, but it works. Oh, please run the test language script on the command line, don't try to load it with a browser, I didn't html encode anything yet. And the one language fileset was copied straight from joomla 1.6 main en-GB files.<br> <br> So, some decisions I've struggled with this week:<br> <ul> <li>Do we want to leave these classes named J* (ie JLoader, JLanguage, JFolder, JPath, JFile, JObject, JFactory, etc) or do we come up with our own prefix? If we do, what prefix should we use? Do we want a prefix at all? (BTW: I'm pretty sure JFactory can probably go away when we load this stuff into our existing Factory class)<br> </li> <li>I am struggling to wrap my brain around the Error classes (ours and theirs). Can someone help me figure out how to get the commented out Error handling to actually function with our error handling classes? And give me a brief explaination of how the error handling classes work and what happens for the user?</li> </ul> As this is a first stab, I'm sure there are still things that can be eliminated or cleaned up yet. I'm thinking all the XML indirection methods maybe could be consolidated a bit :-)<br> <br> -Scott<br> <br> <div class="gmail_quote"> On Fri, Mar 4, 2011 at 7:45 AM, David Thompson <span dir="ltr"><<a moz-do-not-send="true" href="mailto:tom...@us...">tom...@us...</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div> I agree with Scott here, Mark. I think if he can work in the same branch then you will automatically have some else who will test your work (and the other way round). Much better than another dead branch with no-one to test or integrate. Not that anything Scott does ends up being dead code ;-).<br> The translation work doesn't impact the architecture in itself, I hope.<br> Dave<br> <br> <hr> Date: Thu, 3 Mar 2011 15:07:13 +0000 <div class="im"><br> Subject: Re: [Tsheetx-developers] Proposal of contribution for a French version<br> </div> <div class="im">From: <a moz-do-not-send="true" href="mailto:sco...@gm..." target="_blank">sco...@gm...</a><br> </div> To: <a moz-do-not-send="true" href="mailto:ma...@rw..." target="_blank">ma...@rw...</a>; <a moz-do-not-send="true" href="mailto:tom...@us..." target="_blank">tom...@us...</a><br> CC: <a moz-do-not-send="true" href="mailto:tsh...@li..." target="_blank">tsh...@li...</a> <div class="im"> <br> <br> Yes, I saw the email come through about 5 hours after I'd sent it...<br> <br> Brutal is fine :-) I am under no illusions of "cooperation", but I'd thought that perhaps if we made minimal changes to the pieces we wanted we could nearly drop in replacements as Joomla made improvements. But, after starting to look at the work needed, the number of changes we will need to keep from sucking in the whole framework (which I totally agree, we don't want the entire framework) made this thought unrealistic.<br> <br> I understand the fear that perhaps adding internationalization now will hurt the overall progress, but I think this is an important piece, and I've now become familiar enough with the joomla libraries, that I'm not willing to just drop it at this point. I'm hopeful I can hammer out a decent "framework" borrowed and inspired by Joomla that will allow relatively easy translations within a week or two. Plus, the current state of the project says it's quite a long ways off from being released; 3 months or more would be my guess. If we were nearly ready for a release, I would be more easily swayed away :-)<br> <br> Thanks for providing the reality check, I'll start hacking, hammering, and reshaping things to work for us.<br> <br> -Scott<br> <br> <div>On Thu, Mar 3, 2011 at 1:41 PM, Mark Wrightson <span dir="ltr"><<a moz-do-not-send="true" href="mailto:ma...@rw..." target="_blank">ma...@rw...</a>></span> wrote:<br> <blockquote style="padding-left: 1ex;"> <div>Hi Scott, <br> <br> Your emails did come through, i've just been too busy to reply.<br> <br> I think the best idea is to take inspiration from Joomla and other source files you have seen and create your own that suits our requirements that as Dave says won't bloat the project with un-needed functions.<br> <br> I also think we should put translation on the todo list for a point after we have got txsheet fully working and reskinned. Ultimately my main concern is that there are so many changes being made at the moment, if we don't pool our resources and complete them first, we will get to a point where all we will have is a mess.<br> <br> Mark<br> <pre>_____________________________________________ Mob: 07725 695178 Email: <a moz-do-not-send="true" href="mailto:ma...@rw..." target="_blank">ma...@rw...</a></pre> <div> </div> </div> </blockquote> </div> <br> </div> </div> </blockquote> </div> <br> </blockquote> </body> </html> |
From: Scott M. <sco...@gm...> - 2011-03-04 22:25:23
|
Hi guys, I just checked in the minimal amount of code I've sucked in from joomla to get the language stuff to work, and a test script that demonstrates how to load the classes and get the language files loaded. Currently the script just spits out a print_r of a couple classes and some debugging output. So, it's not sexy and pretty yet, but it works. Oh, please run the test language script on the command line, don't try to load it with a browser, I didn't html encode anything yet. And the one language fileset was copied straight from joomla 1.6 main en-GB files. So, some decisions I've struggled with this week: - Do we want to leave these classes named J* (ie JLoader, JLanguage, JFolder, JPath, JFile, JObject, JFactory, etc) or do we come up with our own prefix? If we do, what prefix should we use? Do we want a prefix at all? (BTW: I'm pretty sure JFactory can probably go away when we load this stuff into our existing Factory class) - I am struggling to wrap my brain around the Error classes (ours and theirs). Can someone help me figure out how to get the commented out Error handling to actually function with our error handling classes? And give me a brief explaination of how the error handling classes work and what happens for the user? As this is a first stab, I'm sure there are still things that can be eliminated or cleaned up yet. I'm thinking all the XML indirection methods maybe could be consolidated a bit :-) -Scott On Fri, Mar 4, 2011 at 7:45 AM, David Thompson < tom...@us...> wrote: > I agree with Scott here, Mark. I think if he can work in the same branch > then you will automatically have some else who will test your work (and the > other way round). Much better than another dead branch with no-one to test > or integrate. Not that anything Scott does ends up being dead code ;-). > The translation work doesn't impact the architecture in itself, I hope. > Dave > > ------------------------------ > Date: Thu, 3 Mar 2011 15:07:13 +0000 > > Subject: Re: [Tsheetx-developers] Proposal of contribution for a French > version > From: sco...@gm... > To: ma...@rw...; tom...@us... > CC: tsh...@li... > > > Yes, I saw the email come through about 5 hours after I'd sent it... > > Brutal is fine :-) I am under no illusions of "cooperation", but I'd > thought that perhaps if we made minimal changes to the pieces we wanted we > could nearly drop in replacements as Joomla made improvements. But, after > starting to look at the work needed, the number of changes we will need to > keep from sucking in the whole framework (which I totally agree, we don't > want the entire framework) made this thought unrealistic. > > I understand the fear that perhaps adding internationalization now will > hurt the overall progress, but I think this is an important piece, and I've > now become familiar enough with the joomla libraries, that I'm not willing > to just drop it at this point. I'm hopeful I can hammer out a decent > "framework" borrowed and inspired by Joomla that will allow relatively easy > translations within a week or two. Plus, the current state of the project > says it's quite a long ways off from being released; 3 months or more would > be my guess. If we were nearly ready for a release, I would be more easily > swayed away :-) > > Thanks for providing the reality check, I'll start hacking, hammering, and > reshaping things to work for us. > > -Scott > > On Thu, Mar 3, 2011 at 1:41 PM, Mark Wrightson <ma...@rw...>wrote: > > Hi Scott, > > Your emails did come through, i've just been too busy to reply. > > I think the best idea is to take inspiration from Joomla and other source > files you have seen and create your own that suits our requirements that as > Dave says won't bloat the project with un-needed functions. > > I also think we should put translation on the todo list for a point after > we have got txsheet fully working and reskinned. Ultimately my main concern > is that there are so many changes being made at the moment, if we don't pool > our resources and complete them first, we will get to a point where all we > will have is a mess. > > Mark > > _____________________________________________ > > Mob: 07725 695178 > Email: ma...@rw... > > > |
From: David T. <tom...@us...> - 2011-03-04 07:45:37
|
I agree with Scott here, Mark. I think if he can work in the same branch then you will automatically have some else who will test your work (and the other way round). Much better than another dead branch with no-one to test or integrate. Not that anything Scott does ends up being dead code ;-). The translation work doesn't impact the architecture in itself, I hope. Dave Date: Thu, 3 Mar 2011 15:07:13 +0000 Subject: Re: [Tsheetx-developers] Proposal of contribution for a French version From: sco...@gm... To: ma...@rw...; tom...@us... CC: tsh...@li... Yes, I saw the email come through about 5 hours after I'd sent it... Brutal is fine :-) I am under no illusions of "cooperation", but I'd thought that perhaps if we made minimal changes to the pieces we wanted we could nearly drop in replacements as Joomla made improvements. But, after starting to look at the work needed, the number of changes we will need to keep from sucking in the whole framework (which I totally agree, we don't want the entire framework) made this thought unrealistic. I understand the fear that perhaps adding internationalization now will hurt the overall progress, but I think this is an important piece, and I've now become familiar enough with the joomla libraries, that I'm not willing to just drop it at this point. I'm hopeful I can hammer out a decent "framework" borrowed and inspired by Joomla that will allow relatively easy translations within a week or two. Plus, the current state of the project says it's quite a long ways off from being released; 3 months or more would be my guess. If we were nearly ready for a release, I would be more easily swayed away :-) Thanks for providing the reality check, I'll start hacking, hammering, and reshaping things to work for us. -Scott On Thu, Mar 3, 2011 at 1:41 PM, Mark Wrightson <ma...@rw...> wrote: Hi Scott, Your emails did come through, i've just been too busy to reply. I think the best idea is to take inspiration from Joomla and other source files you have seen and create your own that suits our requirements that as Dave says won't bloat the project with un-needed functions. I also think we should put translation on the todo list for a point after we have got txsheet fully working and reskinned. Ultimately my main concern is that there are so many changes being made at the moment, if we don't pool our resources and complete them first, we will get to a point where all we will have is a mess. Mark _____________________________________________ Mob: 07725 695178 Email: ma...@rw... |
From: Scott M. <sco...@gm...> - 2011-03-03 15:07:30
|
Yes, I saw the email come through about 5 hours after I'd sent it... Brutal is fine :-) I am under no illusions of "cooperation", but I'd thought that perhaps if we made minimal changes to the pieces we wanted we could nearly drop in replacements as Joomla made improvements. But, after starting to look at the work needed, the number of changes we will need to keep from sucking in the whole framework (which I totally agree, we don't want the entire framework) made this thought unrealistic. I understand the fear that perhaps adding internationalization now will hurt the overall progress, but I think this is an important piece, and I've now become familiar enough with the joomla libraries, that I'm not willing to just drop it at this point. I'm hopeful I can hammer out a decent "framework" borrowed and inspired by Joomla that will allow relatively easy translations within a week or two. Plus, the current state of the project says it's quite a long ways off from being released; 3 months or more would be my guess. If we were nearly ready for a release, I would be more easily swayed away :-) Thanks for providing the reality check, I'll start hacking, hammering, and reshaping things to work for us. -Scott On Thu, Mar 3, 2011 at 1:41 PM, Mark Wrightson <ma...@rw...>wrote: > Hi Scott, > > Your emails did come through, i've just been too busy to reply. > > I think the best idea is to take inspiration from Joomla and other source > files you have seen and create your own that suits our requirements that as > Dave says won't bloat the project with un-needed functions. > > I also think we should put translation on the todo list for a point after > we have got txsheet fully working and reskinned. Ultimately my main concern > is that there are so many changes being made at the moment, if we don't pool > our resources and complete them first, we will get to a point where all we > will have is a mess. > > Mark > > _____________________________________________ > > Mob: 07725 695178 > Email: ma...@rw... > > > On 03/03/2011 10:18, David Thompson wrote: > > Scott > Sorry for the late reply, I've been off skiing... > > To be brutal, the gain from "reusing" code from Joomla (or any other > project) is not worth it. Don't be under any illusion that the two projects > will cooperate. If you can see the value in the way that they are made, then > use that, but don't bloat us with functions that are not needed. Rather use > a pure framework (there are enough) for base functions. Zend_translate seems > pretty comprehensive for example. > > But since Mark and Peter have made great efforts to rewrite us without > using a framework, it seems excessive to add one now. Therefore I come back > to my previous suggestion to use base PHP libraries. > > Dave > > ------------------------------ > Date: Wed, 2 Mar 2011 17:15:41 +0000 > From: sco...@gm... > To: tsh...@li... > Subject: Re: [Tsheetx-developers] Proposal of contribution for a French > version > > The silence regarding my last email is deafening. I've begun to think > maybe I should just borrow entire classes, but I don't want this project to > be dependant upon joomla, so we have to draw the line somewhere, but > approximately where is that appropriate line? I'm pretty much unfamiliar > with Joomla, so, uneducated conjecture doesn't get me very far. Do we like > how they handle errors? I'm thinking that we would handle errors > differently than joomla, if so, the error classes should not be included. > > I'd originally thought I'd rename the classes to fit our project, but why > not leave the names the same? If anyone is familiar with Joomla, this might > help other developers improve tsheetx in the future. > > Please help me think through this stuff before I get sucked into a tar pit > :-) > > -Scott > > On Mon, Feb 28, 2011 at 5:56 PM, Scott Miller <sco...@gm...>wrote: > > Hey guys, > > I was intrigued with the JText stuff Isabelle pointed to in Joomla. I > originally was thinking we could just borrow the JText classes etc from > them, but that depends on several other Joomla classes. Some of those are > also intriguing enough that I'm now considering sucking some more base class > stuff from that project. > > Things I think could be useful for tsheetx: > > - JPath - file system path functions > - JFolder - file system folder functions > - JText - language translations > - JObject - generic object class, the others are built from > > I'm sure there are probably other things that could be interesting, but > this is as far as my research has gone thus far. JStream was also > interesting, but there's so much that we don't need that I really don't want > to suck that in too. > > So, I'm sure this is not the first time one project has wanted to borrow > things from a different project. What are the feelings of others on doing > this? Currently, I'm thinking I only want to bring a sub-set of the > functionality provided by those classes. We have little or no need to copy, > create, move, or change files or directories, so, I'm just ripping all the > unneeded functionality out. I will be crediting the Joomla project of > course. > > -Scott > > On Sun, Feb 27, 2011 at 6:02 PM, Isabelle Vergely < > ver...@fr...> wrote: > > Hello Mark, > > I have a little experience with translations with an other CMS: Joomla. > > There is the class "JText" defined in libraries/joomla/methods.php. > > There are the following functions in this class: > > * The function "_" is used for translation of strings without variable; > example: JText ::_('search') with 'search' defined in the "French" file > "language\fr-FR\fr-FR.com_search.ini" as follows: SEARCH=Recherche > > * The function "sprintf" is used for translation of strings containing > variables; > example: JText::sprintf('EMAIL_INVALID', $email) with 'EMAIL_INVALID' > defined in the "English" file "language/en-GB/en-GB.com_mailto.ini" as > follows: > EMAIL_INVALID=The address '%s' does not appear to be a valid e-mail > address > > On Timesheet NG forums, I saw that other people are also interested inTimesheet > NG translation (German, Spanish). > > For version 2.0, if the development team chose to add the ability to easily > translate > Timesheet NG for non-English speakers, I can help you for the translation > into French. > Écouter > Lire phonétiquement > > Dictionnaire - Afficher le dictionnaire<http://www.google.fr/dictionary?source=translation&hl=fr&q=L%27%C3%A9quivalent%20pour%20le%20CMS%20Joomla%20est%20la%20m%C3%A9thode%20JText&langpair=fr%7Cen> > > 1. nom > 1. si > 2. B > 2. adverbe > 1. so > 2. that > 3. such > 4. as > 3. conjonction > 1. if > 2. whether > > > Isabelle. > > > ------------------------------------------------------------------------------ > > > Free Software Download: Index, Search & Analyze Logs and other IT data in > Real-Time with Splunk. Collect, index and harness all the fast moving IT > data > generated by your applications, servers and devices whether physical, > virtual > or in the cloud. Deliver compliance at lower cost and gain new business > insights. http://p.sf.net/sfu/splunk-dev2dev > _______________________________________________ > Tsheetx-developers mailing list > Tsh...@li... > https://lists.sourceforge.net/lists/listinfo/tsheetx-developers > > > > > ------------------------------------------------------------------------------ > Free Software Download: Index, Search & Analyze Logs and other IT data in > Real-Time with Splunk. Collect, index and harness all the fast moving IT > data generated by your applications, servers and devices whether physical, > virtual or in the cloud. Deliver compliance at lower cost and gain new > business insights. http://p.sf.net/sfu/splunk-dev2dev > _______________________________________________ Tsheetx-developers mailing > list Tsh...@li... > https://lists.sourceforge.net/lists/listinfo/tsheetx-developers > > > ------------------------------------------------------------------------------ > Free Software Download: Index, Search & Analyze Logs and other IT data in > Real-Time with Splunk. Collect, index and harness all the fast moving IT data > generated by your applications, servers and devices whether physical, virtual > or in the cloud. Deliver compliance at lower cost and gain new business > insights. http://p.sf.net/sfu/splunk-dev2dev > > > _______________________________________________ > Tsheetx-developers mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/tsheetx-developers > > > > ------------------------------------------------------------------------------ > Free Software Download: Index, Search & Analyze Logs and other IT data in > Real-Time with Splunk. Collect, index and harness all the fast moving IT > data > generated by your applications, servers and devices whether physical, > virtual > or in the cloud. Deliver compliance at lower cost and gain new business > insights. http://p.sf.net/sfu/splunk-dev2dev > _______________________________________________ > Tsheetx-developers mailing list > Tsh...@li... > https://lists.sourceforge.net/lists/listinfo/tsheetx-developers > > |
From: Mark W. <ma...@rw...> - 2011-03-03 13:41:23
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> <title></title> </head> <body text="#000000" bgcolor="#ffffff"> Hi Scott, <br> <br> Your emails did come through, i've just been too busy to reply.<br> <br> I think the best idea is to take inspiration from Joomla and other source files you have seen and create your own that suits our requirements that as Dave says won't bloat the project with un-needed functions.<br> <br> I also think we should put translation on the todo list for a point after we have got txsheet fully working and reskinned. Ultimately my main concern is that there are so many changes being made at the moment, if we don't pool our resources and complete them first, we will get to a point where all we will have is a mess.<br> <br> Mark<br> <pre class="moz-signature" cols="72">_____________________________________________ Mob: 07725 695178 Email: <a class="moz-txt-link-abbreviated" href="mailto:ma...@rw...">ma...@rw...</a></pre> <br> On 03/03/2011 10:18, David Thompson wrote: <blockquote cite="mid:BAY...@ph...l" type="cite"> <style><!-- .hmmessage P { margin:0px; padding:0px } body.hmmessage { font-size: 10pt; font-family:Tahoma } --></style> Scott<br> Sorry for the late reply, I've been off skiing...<br> <br> To be brutal, the gain from "reusing" code from Joomla (or any other project) is not worth it. Don't be under any illusion that the two projects will cooperate. If you can see the value in the way that they are made, then use that, but don't bloat us with functions that are not needed. Rather use a pure framework (there are enough) for base functions. Zend_translate seems pretty comprehensive for example.<br> <br> But since Mark and Peter have made great efforts to rewrite us without using a framework, it seems excessive to add one now. Therefore I come back to my previous suggestion to use base PHP libraries.<br> <br> Dave<br> <br> <hr id="stopSpelling"> Date: Wed, 2 Mar 2011 17:15:41 +0000<br> From: <a class="moz-txt-link-abbreviated" href="mailto:sco...@gm...">sco...@gm...</a><br> To: <a class="moz-txt-link-abbreviated" href="mailto:tsh...@li...">tsh...@li...</a><br> Subject: Re: [Tsheetx-developers] Proposal of contribution for a French version<br> <br> The silence regarding my last email is deafening. I've begun to think maybe I should just borrow entire classes, but I don't want this project to be dependant upon joomla, so we have to draw the line somewhere, but approximately where is that appropriate line? I'm pretty much unfamiliar with Joomla, so, uneducated conjecture doesn't get me very far. Do we like how they handle errors? I'm thinking that we would handle errors differently than joomla, if so, the error classes should not be included.<br> <br> I'd originally thought I'd rename the classes to fit our project, but why not leave the names the same? If anyone is familiar with Joomla, this might help other developers improve tsheetx in the future.<br> <br> Please help me think through this stuff before I get sucked into a tar pit :-)<br> <br> -Scott<br> <br> <div class="ecxgmail_quote">On Mon, Feb 28, 2011 at 5:56 PM, Scott Miller <span dir="ltr"><<a moz-do-not-send="true" href="mailto:sco...@gm...">sco...@gm...</a>></span> wrote:<br> <blockquote style="padding-left: 1ex;" class="ecxgmail_quote">Hey guys,<br> <br> I was intrigued with the JText stuff Isabelle pointed to in Joomla. I originally was thinking we could just borrow the JText classes etc from them, but that depends on several other Joomla classes. Some of those are also intriguing enough that I'm now considering sucking some more base class stuff from that project.<br> <br> Things I think could be useful for tsheetx:<br> <ul> <li>JPath - file system path functions<br> </li> <li>JFolder - file system folder functions</li> <li>JText - language translations</li> <li>JObject - generic object class, the others are built from<br> </li> </ul> I'm sure there are probably other things that could be interesting, but this is as far as my research has gone thus far. JStream was also interesting, but there's so much that we don't need that I really don't want to suck that in too.<br> <br> So, I'm sure this is not the first time one project has wanted to borrow things from a different project. What are the feelings of others on doing this? Currently, I'm thinking I only want to bring a sub-set of the functionality provided by those classes. We have little or no need to copy, create, move, or change files or directories, so, I'm just ripping all the unneeded functionality out. I will be crediting the Joomla project of course.<br> <font color="#888888"><br> -Scott<br> <br> </font> <div class="ecxgmail_quote"> <div> <div class="h5">On Sun, Feb 27, 2011 at 6:02 PM, Isabelle Vergely <span dir="ltr"><<a moz-do-not-send="true" href="mailto:ver...@fr...">ver...@fr...</a>></span> wrote:<br> </div> </div> <blockquote style="padding-left: 1ex;" class="ecxgmail_quote"> <div> <div class="h5"> <div> <div style="font-family: Arial; color: rgb(0, 0, 0); font-size: 10pt;"> <div style="font-family: Arial; color: rgb(0, 0, 0); font-size: 10pt;">Hello Mark,<br> <br> I have a little experience with translations with an other CMS: Joomla.<br> <br> There is the class "JText" defined in libraries/joomla/methods.php.<br> <br> There are the following functions in this class:<br> <br> * The function "_" is used for translation of strings without variable;<br> example: JText ::_('search') with 'search' defined in the "French" file<br> "language\fr-FR\fr-FR.com_search.ini" as follows: SEARCH=Recherche<br> <br> * The function "sprintf" is used for translation of strings containing variables;<br> example: JText::sprintf('EMAIL_INVALID', $email) with 'EMAIL_INVALID'<br> defined in the "English" file "language/en-GB/en-GB.com_mailto.ini" as follows:<br> EMAIL_INVALID=The address '%s' does not appear to be a valid e-mail address<br> <br> <div> <div dir="ltr"><span lang="en"><span title="Cliquer ici pour voir d'autres traductions">On Timesheet</span> <span title="Cliquer ici pour voir d'autres traductions">NG forums</span><span title="Cliquer ici pour voir d'autres traductions">, I</span> <span title="Cliquer ici pour voir d'autres traductions">saw</span> <span title="Cliquer ici pour voir d'autres traductions">that other</span> <span title="Cliquer ici pour voir d'autres traductions">people</span> <span title="Cliquer ici pour voir d'autres traductions">are</span> <span title="Cliquer ici pour voir d'autres traductions">also</span> <span title="Cliquer ici pour voir d'autres traductions">interested</span> <span title="Cliquer ici pour voir d'autres traductions">in</span> Timesheet<br> <span title="Cliquer ici pour voir d'autres traductions">NG translation</span><span title="Cliquer ici pour voir d'autres traductions"></span> <span title="Cliquer ici pour voir d'autres traductions">(</span><span title="Cliquer ici pour voir d'autres traductions">German</span><span title="Cliquer ici pour voir d'autres traductions">,</span> <span title="Cliquer ici pour voir d'autres traductions">Spanish</span><span title="Cliquer ici pour voir d'autres traductions">)</span><span title="Cliquer ici pour voir d'autres traductions">.</span><br> <br> <span title="Cliquer ici pour voir d'autres traductions">For</span> <span title="Cliquer ici pour voir d'autres traductions">version</span> <span title="Cliquer ici pour voir d'autres traductions">2.0,</span> <span title="Cliquer ici pour voir d'autres traductions">if</span> <span title="Cliquer ici pour voir d'autres traductions">the</span> <span title="Cliquer ici pour voir d'autres traductions">development team</span> <span title="Cliquer ici pour voir d'autres traductions">chose</span> <span title="Cliquer ici pour voir d'autres traductions">to</span> <span title="Cliquer ici pour voir d'autres traductions">add</span> <span title="Cliquer ici pour voir d'autres traductions">the ability</span> <span title="Cliquer ici pour voir d'autres traductions">to</span> <span title="Cliquer ici pour voir d'autres traductions">easily translate</span> <br> Timesheet NG <span title="Cliquer ici pour voir d'autres traductions">for</span> <span title="Cliquer ici pour voir d'autres traductions">non</span><span title="Cliquer ici pour voir d'autres traductions">-</span><span title="Cliquer ici pour voir d'autres traductions">English speakers</span><span title="Cliquer ici pour voir d'autres traductions">,</span> <span title="Cliquer ici pour voir d'autres traductions">I</span> <span title="Cliquer ici pour voir d'autres traductions">can help you for</span> <span title="Cliquer ici pour voir d'autres traductions">the translation</span> <span title="Cliquer ici pour voir d'autres traductions">into</span> <span title="Cliquer ici pour voir d'autres traductions">French</span><span title="Cliquer ici pour voir d'autres traductions">.</span></span></div> </div> <div> <div><span></span><span>Écouter</span></div> <div><span></span><span>Lire phonétiquement</span></div> </div> <div dir="ltr"> </div> <div> <h3>Dictionnaire<span> - <a moz-do-not-send="true" href="http://www.google.fr/dictionary?source=translation&hl=fr&q=L%27%C3%A9quivalent%20pour%20le%20CMS%20Joomla%20est%20la%20m%C3%A9thode%20JText&langpair=fr%7Cen" target="_blank">Afficher le dictionnaire</a></span></h3> <ol> <li>nom <ol> <li>si</li> <li>B</li> </ol> </li> <li>adverbe <ol> <li>so</li> <li>that</li> <li>such</li> <li>as</li> </ol> </li> <li>conjonction <ol> <li>if</li> <li>whether</li> </ol> </li> </ol> </div> <br> <font color="#888888">Isabelle.<br> <br> </font></div> </div> </div> <br> </div> </div> ------------------------------------------------------------------------------ <div class="ecxim"><br> Free Software Download: Index, Search & Analyze Logs and other IT data in<br> Real-Time with Splunk. Collect, index and harness all the fast moving IT data<br> generated by your applications, servers and devices whether physical, virtual<br> or in the cloud. Deliver compliance at lower cost and gain new business<br> insights. <a moz-do-not-send="true" href="http://p.sf.net/sfu/splunk-dev2dev" target="_blank">http://p.sf.net/sfu/splunk-dev2dev</a> <br> _______________________________________________<br> Tsheetx-developers mailing list<br> <a moz-do-not-send="true" href="mailto:Tsh...@li...">Tsh...@li...</a><br> <a moz-do-not-send="true" href="https://lists.sourceforge.net/lists/listinfo/tsheetx-developers" target="_blank">https://lists.sourceforge.net/lists/listinfo/tsheetx-developers</a><br> <br> </div> </blockquote> </div> <br> </blockquote> </div> <br> <br> ------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. <a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/splunk-dev2dev">http://p.sf.net/sfu/splunk-dev2dev</a><br> _______________________________________________ Tsheetx-developers mailing list <a class="moz-txt-link-abbreviated" href="mailto:Tsh...@li...">Tsh...@li...</a> <a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/tsheetx-developers">https://lists.sourceforge.net/lists/listinfo/tsheetx-developers</a> <pre wrap=""> <fieldset class="mimeAttachmentHeader"></fieldset> ------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. <a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/splunk-dev2dev">http://p.sf.net/sfu/splunk-dev2dev</a> </pre> <pre wrap=""> <fieldset class="mimeAttachmentHeader"></fieldset> _______________________________________________ Tsheetx-developers mailing list <a class="moz-txt-link-abbreviated" href="mailto:Tsh...@li...">Tsh...@li...</a> <a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/tsheetx-developers">https://lists.sourceforge.net/lists/listinfo/tsheetx-developers</a> </pre> </blockquote> </body> </html> |
From: David T. <tom...@us...> - 2011-03-03 10:19:03
|
Scott Sorry for the late reply, I've been off skiing... To be brutal, the gain from "reusing" code from Joomla (or any other project) is not worth it. Don't be under any illusion that the two projects will cooperate. If you can see the value in the way that they are made, then use that, but don't bloat us with functions that are not needed. Rather use a pure framework (there are enough) for base functions. Zend_translate seems pretty comprehensive for example. But since Mark and Peter have made great efforts to rewrite us without using a framework, it seems excessive to add one now. Therefore I come back to my previous suggestion to use base PHP libraries. Dave Date: Wed, 2 Mar 2011 17:15:41 +0000 From: sco...@gm... To: tsh...@li... Subject: Re: [Tsheetx-developers] Proposal of contribution for a French version The silence regarding my last email is deafening. I've begun to think maybe I should just borrow entire classes, but I don't want this project to be dependant upon joomla, so we have to draw the line somewhere, but approximately where is that appropriate line? I'm pretty much unfamiliar with Joomla, so, uneducated conjecture doesn't get me very far. Do we like how they handle errors? I'm thinking that we would handle errors differently than joomla, if so, the error classes should not be included. I'd originally thought I'd rename the classes to fit our project, but why not leave the names the same? If anyone is familiar with Joomla, this might help other developers improve tsheetx in the future. Please help me think through this stuff before I get sucked into a tar pit :-) -Scott On Mon, Feb 28, 2011 at 5:56 PM, Scott Miller <sco...@gm...> wrote: Hey guys, I was intrigued with the JText stuff Isabelle pointed to in Joomla. I originally was thinking we could just borrow the JText classes etc from them, but that depends on several other Joomla classes. Some of those are also intriguing enough that I'm now considering sucking some more base class stuff from that project. Things I think could be useful for tsheetx: JPath - file system path functions JFolder - file system folder functions JText - language translations JObject - generic object class, the others are built from I'm sure there are probably other things that could be interesting, but this is as far as my research has gone thus far. JStream was also interesting, but there's so much that we don't need that I really don't want to suck that in too. So, I'm sure this is not the first time one project has wanted to borrow things from a different project. What are the feelings of others on doing this? Currently, I'm thinking I only want to bring a sub-set of the functionality provided by those classes. We have little or no need to copy, create, move, or change files or directories, so, I'm just ripping all the unneeded functionality out. I will be crediting the Joomla project of course. -Scott On Sun, Feb 27, 2011 at 6:02 PM, Isabelle Vergely <ver...@fr...> wrote: Hello Mark, I have a little experience with translations with an other CMS: Joomla. There is the class "JText" defined in libraries/joomla/methods.php. There are the following functions in this class: * The function "_" is used for translation of strings without variable; example: JText ::_('search') with 'search' defined in the "French" file "language\fr-FR\fr-FR.com_search.ini" as follows: SEARCH=Recherche * The function "sprintf" is used for translation of strings containing variables; example: JText::sprintf('EMAIL_INVALID', $email) with 'EMAIL_INVALID' defined in the "English" file "language/en-GB/en-GB.com_mailto.ini" as follows: EMAIL_INVALID=The address '%s' does not appear to be a valid e-mail address On Timesheet NG forums, I saw that other people are also interested in Timesheet NG translation (German, Spanish). For version 2.0, if the development team chose to add the ability to easily translate Timesheet NG for non-English speakers, I can help you for the translation into French. Écouter Lire phonétiquement Dictionnaire - Afficher le dictionnaire nom si B adverbe so that such as conjonction if whether Isabelle. ------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev _______________________________________________ Tsheetx-developers mailing list Tsh...@li... https://lists.sourceforge.net/lists/listinfo/tsheetx-developers ------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev _______________________________________________ Tsheetx-developers mailing list Tsh...@li... https://lists.sourceforge.net/lists/listinfo/tsheetx-developers |
From: Scott M. <sco...@gm...> - 2011-03-02 17:22:22
|
The silence regarding my last email is deafening. I've begun to think maybe I should just borrow entire classes, but I don't want this project to be dependant upon joomla, so we have to draw the line somewhere, but approximately where is that appropriate line? I'm pretty much unfamiliar with Joomla, so, uneducated conjecture doesn't get me very far. Do we like how they handle errors? I'm thinking that we would handle errors differently than joomla, if so, the error classes should not be included. I'd originally thought I'd rename the classes to fit our project, but why not leave the names the same? If anyone is familiar with Joomla, this might help other developers improve tsheetx in the future. Please help me think through this stuff before I get sucked into a tar pit :-) -Scott On Mon, Feb 28, 2011 at 5:56 PM, Scott Miller <sco...@gm...>wrote: > Hey guys, > > I was intrigued with the JText stuff Isabelle pointed to in Joomla. I > originally was thinking we could just borrow the JText classes etc from > them, but that depends on several other Joomla classes. Some of those are > also intriguing enough that I'm now considering sucking some more base class > stuff from that project. > > Things I think could be useful for tsheetx: > > - JPath - file system path functions > - JFolder - file system folder functions > - JText - language translations > - JObject - generic object class, the others are built from > > I'm sure there are probably other things that could be interesting, but > this is as far as my research has gone thus far. JStream was also > interesting, but there's so much that we don't need that I really don't want > to suck that in too. > > So, I'm sure this is not the first time one project has wanted to borrow > things from a different project. What are the feelings of others on doing > this? Currently, I'm thinking I only want to bring a sub-set of the > functionality provided by those classes. We have little or no need to copy, > create, move, or change files or directories, so, I'm just ripping all the > unneeded functionality out. I will be crediting the Joomla project of > course. > > -Scott > > On Sun, Feb 27, 2011 at 6:02 PM, Isabelle Vergely < > ver...@fr...> wrote: > >> Hello Mark, >> >> I have a little experience with translations with an other CMS: Joomla. >> >> There is the class "JText" defined in libraries/joomla/methods.php. >> >> There are the following functions in this class: >> >> * The function "_" is used for translation of strings without variable; >> example: JText ::_('search') with 'search' defined in the "French" file >> "language\fr-FR\fr-FR.com_search.ini" as follows: SEARCH=Recherche >> >> * The function "sprintf" is used for translation of strings containing >> variables; >> example: JText::sprintf('EMAIL_INVALID', $email) with 'EMAIL_INVALID' >> defined in the "English" file "language/en-GB/en-GB.com_mailto.ini" as >> follows: >> EMAIL_INVALID=The address '%s' does not appear to be a valid e-mail >> address >> >> On Timesheet NG forums, I saw that other people are also interested inTimesheet >> NG translation (German, Spanish). >> >> For version 2.0, if the development team chose to add the ability to easily >> translate >> Timesheet NG for non-English speakers, I can help you for the translation >> into French. >> Écouter >> Lire phonétiquement >> >> Dictionnaire - Afficher le dictionnaire<http://www.google.fr/dictionary?source=translation&hl=fr&q=L%27%C3%A9quivalent%20pour%20le%20CMS%20Joomla%20est%20la%20m%C3%A9thode%20JText&langpair=fr%7Cen> >> >> 1. nom >> 1. si >> 2. B >> 2. adverbe >> 1. so >> 2. that >> 3. such >> 4. as >> 3. conjonction >> 1. if >> 2. whether >> >> >> Isabelle. >> >> >> >> ------------------------------------------------------------------------------ >> >> Free Software Download: Index, Search & Analyze Logs and other IT data in >> Real-Time with Splunk. Collect, index and harness all the fast moving IT >> data >> generated by your applications, servers and devices whether physical, >> virtual >> or in the cloud. Deliver compliance at lower cost and gain new business >> insights. http://p.sf.net/sfu/splunk-dev2dev >> _______________________________________________ >> Tsheetx-developers mailing list >> Tsh...@li... >> https://lists.sourceforge.net/lists/listinfo/tsheetx-developers >> >> > |
From: Scott M. <sco...@gm...> - 2011-02-28 17:56:20
|
Hey guys, I was intrigued with the JText stuff Isabelle pointed to in Joomla. I originally was thinking we could just borrow the JText classes etc from them, but that depends on several other Joomla classes. Some of those are also intriguing enough that I'm now considering sucking some more base class stuff from that project. Things I think could be useful for tsheetx: - JPath - file system path functions - JFolder - file system folder functions - JText - language translations - JObject - generic object class, the others are built from I'm sure there are probably other things that could be interesting, but this is as far as my research has gone thus far. JStream was also interesting, but there's so much that we don't need that I really don't want to suck that in too. So, I'm sure this is not the first time one project has wanted to borrow things from a different project. What are the feelings of others on doing this? Currently, I'm thinking I only want to bring a sub-set of the functionality provided by those classes. We have little or no need to copy, create, move, or change files or directories, so, I'm just ripping all the unneeded functionality out. I will be crediting the Joomla project of course. -Scott On Sun, Feb 27, 2011 at 6:02 PM, Isabelle Vergely <ver...@fr...>wrote: > Hello Mark, > > I have a little experience with translations with an other CMS: Joomla. > > There is the class "JText" defined in libraries/joomla/methods.php. > > There are the following functions in this class: > > * The function "_" is used for translation of strings without variable; > example: JText ::_('search') with 'search' defined in the "French" file > "language\fr-FR\fr-FR.com_search.ini" as follows: SEARCH=Recherche > > * The function "sprintf" is used for translation of strings containing > variables; > example: JText::sprintf('EMAIL_INVALID', $email) with 'EMAIL_INVALID' > defined in the "English" file "language/en-GB/en-GB.com_mailto.ini" as > follows: > EMAIL_INVALID=The address '%s' does not appear to be a valid e-mail > address > > On Timesheet NG forums, I saw that other people are also interested inTimesheet > NG translation (German, Spanish). > > For version 2.0, if the development team chose to add the ability to easily > translate > Timesheet NG for non-English speakers, I can help you for the translation > into French. > Écouter > Lire phonétiquement > > Dictionnaire - Afficher le dictionnaire<http://www.google.fr/dictionary?source=translation&hl=fr&q=L%27%C3%A9quivalent%20pour%20le%20CMS%20Joomla%20est%20la%20m%C3%A9thode%20JText&langpair=fr%7Cen> > > 1. nom > 1. si > 2. B > 2. adverbe > 1. so > 2. that > 3. such > 4. as > 3. conjonction > 1. if > 2. whether > > > Isabelle. > > > > ------------------------------------------------------------------------------ > Free Software Download: Index, Search & Analyze Logs and other IT data in > Real-Time with Splunk. Collect, index and harness all the fast moving IT > data > generated by your applications, servers and devices whether physical, > virtual > or in the cloud. Deliver compliance at lower cost and gain new business > insights. http://p.sf.net/sfu/splunk-dev2dev > _______________________________________________ > Tsheetx-developers mailing list > Tsh...@li... > https://lists.sourceforge.net/lists/listinfo/tsheetx-developers > > |
From: Isabelle V. <ver...@fr...> - 2011-02-27 18:02:21
|
Hello Mark, I have a little experience with translations with an other CMS: Joomla. There is the class "JText" defined in libraries/joomla/methods.php. There are the following functions in this class: * The function "_" is used for translation of strings without variable; example: JText ::_('search') with 'search' defined in the "French" file "language\fr-FR\fr-FR.com_search.ini" as follows: SEARCH=Recherche * The function "sprintf" is used for translation of strings containing variables; example: JText::sprintf('EMAIL_INVALID', $email) with 'EMAIL_INVALID' defined in the "English" file "language/en-GB/en-GB.com_mailto.ini" as follows: EMAIL_INVALID=The address '%s' does not appear to be a valid e-mail address On Timesheet NG forums , I saw that other people are also interested in Timesheet NG translation ( German , Spanish ) . For version 2.0, if the development team chose to add the ability to easily translate Timesheet NG for non - English speakers , I can help you for the translation into French . Écouter Lire phonétiquement Dictionnaire - Afficher le dictionnaire 1. nom 1. si 2. B 2. adverbe 1. so 2. that 3. such 4. as 3. conjonction 1. if 2. whether Isabelle. |
From: Mark W. <ma...@rw...> - 2011-02-25 22:36:03
|
I think something along those lines would work. Quite a lot of work was done to that effect with a port of timesheet for the Xoops Content Management System. See: http://sourceforge.net/projects/timesheetxoops/ This was the original version of timesheet that I came across and used and modified before finding the nextgen project. I think we could update the way Isabelle's language stuff works to be more object orientated. The principle however is sound. Maybe a look at drupal may be interesting. They have something to do with a $t() function. Don't know much about it though. Mark On 25/02/2011 18:49, Isabelle Vergely wrote: > Here is an example with some text in french in a file > "lang/fr-lang.php" for the login page of Timesheet: > > --------------------------------------------------------------------- > > <?php > > include(dirname(__FILE__)."/../common.inc"); > $ver = getVersion(); > > > //------------------------------------------------------------------- > // Some translations for login.php > //------------------------------------------------------------------- > define('_TSNGTXT_LOGIN_USERNAME', 'Utilisateur'); > define('_TSNGTXT_LOGIN_PASSWORD', 'Mot de passe'); > define('_TSNGTXT_LOGIN_HEADTITLE', 'TimesheetNextGen '.$ver.' | > Connexion'); > define('_TSNGTXT_LOGIN_TABLETITLE', 'Connexion à > TimesheetNextGen '.$ver); > > ?> > > --------------------------------------------------------------------- > > And, for example, in the page "login.php", the line code for these > html title of the page: > > --------------------------------------------------------------------- > > <title><?php echo _TSNGTXT_LOGIN_HEADTITLE; ?></title> > > --------------------------------------------------------------------- > > The result is, for example, for the title page of login.php: > TimesheetNextGen 1.5.2 | Connexion > > For accented letters , the result is fine using html entities as in > "_TSNGTXT_LOGIN_TABLETITLE". > > I hope this help you. > > Good week-end! > > Isabelle. > > ----- Mail Original ----- > De: "Scott Miller" <sco...@gm...> > À: "Isabelle Vergely" <ver...@fr...>, "tsheetx" > <tsh...@li...> > Envoyé: Vendredi 25 Février 2011 17:54:37 GMT +01:00 Amsterdam / > Berlin / Berne / Rome / Stockholm / Vienne > Objet: Re: [Tsheetx-developers] Proposal of contribution for a French > version > > I'm unfamiliar with how this would work, could you give us a smaillish > concrete example? > > -Scott > > > On Thu, Feb 24, 2011 at 6:56 PM, Isabelle Vergely < > ver...@fr... > wrote: > > > > > David, and Scott, > > Regardless of the version of Timesheet, it seems to me that using > gettext (GNU) is not very suitable because sometimes you have to > translate sentences containing variables. > In addition, sentence structure changes from one language to another. > > For me, it would be easier and more flexible to use language files > (eg fr-lang.php) using define() instructions and to test the locale > specified in the configuration of Timesheet to include the right > language file. > > For the display of dates, I replaced all "date()" by "strftime()". > > Funny thing for the "French locale" with Timesheet: > setlocale(LC_ALL, 'fr_FR') is not sufficient for to have all date > formats correctly displayed in French. > But, all dates are OK with setlocale(LC_ALL, 'fr_FR', 'fra'). > > Isabelle. > > ----- Mail Original ----- > De: "David Thompson" < tom...@us... > > À: "vergely isabelle" < ver...@fr... > > Cc: tsh...@li... > Envoyé: Jeudi 24 Février 2011 16:41:36 GMT +01:00 Amsterdam / Berlin / > Berne / Rome / Stockholm / Vienne > Objet: RE: [Tsheetx-developers] Proposal of contribution for a French > version > > > We have had a couple of people suggesting a translation, but you are > the first to "produce the goods". Well done. > > The only question is how to sensibly integrate it. It comes under I18N > problems. In the past we looked at php.gettext which would be > relatively easy to use (especially that you have found all the text > places to change - by translating them in place), but it depends a bit > on your server setup. To be flexible, in the long term, my feeling is > that it will need a user config field to define each user's locale, > but you are probably OK with the global locale setting. > > Would you be able to contribute your changes as a developer? We would > welcome any help you can give. > > Cheers > tommo > > > Date: Thu, 24 Feb 2011 15:15:05 +0100 > From: ver...@fr... > To: tsh...@li... > Subject: [Tsheetx-developers] Proposal of contribution for a French > version > > > > > Hello, > > I'm French. > > For my work, I identified Timesheet Next Gen 1.5.2 as a good open > source tool for recording the time spent on project tasks. > > Unfortunately, I quickly realized that its structure did not allow > easily to have versions with other languages than English. > I don't know if is planned a future version of Timesheet NG with a > structure that facilitates its use for non-English speaking users by > choosing the language and having different language files available. > > Whatever it is, I undertook the translation into French of the > application (.php and .inc files, database field values like enum > types) maintaining the current structure of Timesheet 1.5.2. This work > is almost finished. > Also, I made small changes to the display of some pages. > > So, I can contribute to the diffusion of Timeshheet Next Gen in French. > > Best regards. > > Isabelle. > > ------------------------------------------------------------------------------ > > Free Software Download: Index, Search & Analyze Logs and other IT data in > Real-Time with Splunk. Collect, index and harness all the fast moving > IT data > generated by your applications, servers and devices whether physical, > virtual > or in the cloud. Deliver compliance at lower cost and gain new business > insights. http://p.sf.net/sfu/splunk-dev2dev > _______________________________________________ > Tsheetx-developers mailing list > Tsh...@li... > https://lists.sourceforge.net/lists/listinfo/tsheetx-developers > > > > ------------------------------------------------------------------------------ > Free Software Download: Index, Search& Analyze Logs and other IT data in > Real-Time with Splunk. Collect, index and harness all the fast moving IT data > generated by your applications, servers and devices whether physical, virtual > or in the cloud. Deliver compliance at lower cost and gain new business > insights. http://p.sf.net/sfu/splunk-dev2dev > > > _______________________________________________ > Tsheetx-developers mailing list > Tsh...@li... > https://lists.sourceforge.net/lists/listinfo/tsheetx-developers |
From: Isabelle V. <ver...@fr...> - 2011-02-25 18:49:35
|
Here is an example with some text in french in a file "lang/fr-lang.php" for the login page of Timesheet: --------------------------------------------------------------------- <?php include(dirname(__FILE__)."/../common.inc"); $ver = getVersion(); //------------------------------------------------------------------- // Some translations for login.php //------------------------------------------------------------------- define('_TSNGTXT_LOGIN_USERNAME', 'Utilisateur'); define('_TSNGTXT_LOGIN_PASSWORD', 'Mot de passe'); define('_TSNGTXT_LOGIN_HEADTITLE', 'TimesheetNextGen '.$ver.' | Connexion'); define('_TSNGTXT_LOGIN_TABLETITLE', 'Connexion à TimesheetNextGen '.$ver); ?> --------------------------------------------------------------------- And, for example, in the page "login.php", the line code for these html title of the page: --------------------------------------------------------------------- <title><?php echo _TSNGTXT_LOGIN_HEADTITLE; ?></title> --------------------------------------------------------------------- The result is, for example, for the title page of login.php: TimesheetNextGen 1.5.2 | Connexion For accented letters , the result is fine using html entities as in "_TSNGTXT_LOGIN_TABLETITLE". I hope this help you. Good week-end! Isabelle. ----- Mail Original ----- De: "Scott Miller" <sco...@gm...> À: "Isabelle Vergely" <ver...@fr...>, "tsheetx" <tsh...@li...> Envoyé: Vendredi 25 Février 2011 17:54:37 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: Re: [Tsheetx-developers] Proposal of contribution for a French version I'm unfamiliar with how this would work, could you give us a smaillish concrete example? -Scott On Thu, Feb 24, 2011 at 6:56 PM, Isabelle Vergely < ver...@fr... > wrote: David, and Scott, Regardless of the version of Timesheet, it seems to me that using gettext (GNU) is not very suitable because sometimes you have to translate sentences containing variables. In addition, sentence structure changes from one language to another. For me, it would be easier and more flexible to use language files (eg fr-lang.php) using define() instructions and to test the locale specified in the configuration of Timesheet to include the right language file. For the display of dates, I replaced all "date()" by "strftime()". Funny thing for the "French locale" with Timesheet: setlocale(LC_ALL, 'fr_FR') is not sufficient for to have all date formats correctly displayed in French. But, all dates are OK with setlocale(LC_ALL, 'fr_FR', 'fra'). Isabelle. ----- Mail Original ----- De: "David Thompson" < tom...@us... > À: "vergely isabelle" < ver...@fr... > Cc: tsh...@li... Envoyé: Jeudi 24 Février 2011 16:41:36 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: RE: [Tsheetx-developers] Proposal of contribution for a French version We have had a couple of people suggesting a translation, but you are the first to "produce the goods". Well done. The only question is how to sensibly integrate it. It comes under I18N problems. In the past we looked at php.gettext which would be relatively easy to use (especially that you have found all the text places to change - by translating them in place), but it depends a bit on your server setup. To be flexible, in the long term, my feeling is that it will need a user config field to define each user's locale, but you are probably OK with the global locale setting. Would you be able to contribute your changes as a developer? We would welcome any help you can give. Cheers tommo Date: Thu, 24 Feb 2011 15:15:05 +0100 From: ver...@fr... To: tsh...@li... Subject: [Tsheetx-developers] Proposal of contribution for a French version Hello, I'm French. For my work, I identified Timesheet Next Gen 1.5.2 as a good open source tool for recording the time spent on project tasks. Unfortunately, I quickly realized that its structure did not allow easily to have versions with other languages than English. I don't know if is planned a future version of Timesheet NG with a structure that facilitates its use for non-English speaking users by choosing the language and having different language files available. Whatever it is, I undertook the translation into French of the application (.php and .inc files, database field values like enum types) maintaining the current structure of Timesheet 1.5.2. This work is almost finished. Also, I made small changes to the display of some pages. So, I can contribute to the diffusion of Timeshheet Next Gen in French. Best regards. Isabelle. ------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev _______________________________________________ Tsheetx-developers mailing list Tsh...@li... https://lists.sourceforge.net/lists/listinfo/tsheetx-developers |
From: Scott M. <sco...@gm...> - 2011-02-25 16:54:40
|
I'm unfamiliar with how this would work, could you give us a smaillish concrete example? -Scott On Thu, Feb 24, 2011 at 6:56 PM, Isabelle Vergely <ver...@fr...>wrote: > David, and Scott, > > Regardless of the version of Timesheet, it seems to me that using > gettext (GNU) is not very suitable because sometimes you have to > translate sentences containing variables. > In addition, sentence structure changes from one language to another. > > For me, it would be easier and more flexible to use language files > (eg fr-lang.php) using define() instructions and to test the locale > specified in the configuration of Timesheet to include the right > language file. > > For the display of dates, I replaced all "date()" by "strftime()". > > Funny thing for the "French locale" with Timesheet: > setlocale(LC_ALL, 'fr_FR') is not sufficient for to have all date > formats correctly displayed in French. > But, all dates are OK with setlocale(LC_ALL, 'fr_FR', 'fra'). > > Isabelle. > > ----- Mail Original ----- > De: "David Thompson" <tom...@us...> > À: "vergely isabelle" <ver...@fr...> > Cc: tsh...@li... > Envoyé: Jeudi 24 Février 2011 16:41:36 GMT +01:00 Amsterdam / Berlin / > Berne / Rome / Stockholm / Vienne > Objet: RE: [Tsheetx-developers] Proposal of contribution for a French > version > > > We have had a couple of people suggesting a translation, but you are the > first to "produce the goods". Well done. > > The only question is how to sensibly integrate it. It comes under I18N > problems. In the past we looked at php.gettext which would be relatively > easy to use (especially that you have found all the text places to change - > by translating them in place), but it depends a bit on your server setup. To > be flexible, in the long term, my feeling is that it will need a user config > field to define each user's locale, but you are probably OK with the global > locale setting. > > Would you be able to contribute your changes as a developer? We would > welcome any help you can give. > > Cheers > tommo > > ------------------------------ > Date: Thu, 24 Feb 2011 15:15:05 +0100 > From: ver...@fr... > To: tsh...@li... > Subject: [Tsheetx-developers] Proposal of contribution for a French version > > Hello, > > I'm French. > > For my work, I identified Timesheet Next Gen 1.5.2 as a good open source > tool for recording the time spent on project tasks. > > Unfortunately, I quickly realized that its structure did not allow easily > to have versions with other languages than English. > I don't know if is planned a future version of Timesheet NG with a > structure that facilitates its use for non-English speaking users by > choosing the language and having different language files available. > > Whatever it is, I undertook the translation into French of the application > (.php and .inc files, database field values like enum types) maintaining the > current structure of Timesheet 1.5.2. This work is almost finished. > Also, I made small changes to the display of some pages. > > So, I can contribute to the diffusion of Timeshheet Next Gen in French. > > Best regards. > > Isabelle. > > > ------------------------------------------------------------------------------ > Free Software Download: Index, Search & Analyze Logs and other IT data in > Real-Time with Splunk. Collect, index and harness all the fast moving IT > data > generated by your applications, servers and devices whether physical, > virtual > or in the cloud. Deliver compliance at lower cost and gain new business > insights. http://p.sf.net/sfu/splunk-dev2dev > _______________________________________________ > Tsheetx-developers mailing list > Tsh...@li... > https://lists.sourceforge.net/lists/listinfo/tsheetx-developers > > |
From: Isabelle V. <ver...@fr...> - 2011-02-24 18:56:13
|
David, and Scott, Regardless of the version of Timesheet, it seems to me that using gettext (GNU) is not very suitable because sometimes you have to translate sentences containing variables. In addition, sentence structure changes from one language to another. For me, it would be easier and more flexible to use language files (eg fr-lang.php) using define() instructions and to test the locale specified in the configuration of Timesheet to include the right language file. For the display of dates, I replaced all "date()" by "strftime()". Funny thing for the "French locale" with Timesheet: setlocale(LC_ALL, 'fr_FR') is not sufficient for to have all date formats correctly displayed in French. But, all dates are OK with setlocale(LC_ALL, 'fr_FR', 'fra'). Isabelle. ----- Mail Original ----- De: "David Thompson" <tom...@us...> À: "vergely isabelle" <ver...@fr...> Cc: tsh...@li... Envoyé: Jeudi 24 Février 2011 16:41:36 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: RE: [Tsheetx-developers] Proposal of contribution for a French version We have had a couple of people suggesting a translation, but you are the first to "produce the goods". Well done. The only question is how to sensibly integrate it. It comes under I18N problems. In the past we looked at php.gettext which would be relatively easy to use (especially that you have found all the text places to change - by translating them in place), but it depends a bit on your server setup. To be flexible, in the long term, my feeling is that it will need a user config field to define each user's locale, but you are probably OK with the global locale setting. Would you be able to contribute your changes as a developer? We would welcome any help you can give. Cheers tommo Date: Thu, 24 Feb 2011 15:15:05 +0100 From: ver...@fr... To: tsh...@li... Subject: [Tsheetx-developers] Proposal of contribution for a French version Hello, I'm French. For my work, I identified Timesheet Next Gen 1.5.2 as a good open source tool for recording the time spent on project tasks. Unfortunately, I quickly realized that its structure did not allow easily to have versions with other languages than English. I don't know if is planned a future version of Timesheet NG with a structure that facilitates its use for non-English speaking users by choosing the language and having different language files available. Whatever it is, I undertook the translation into French of the application (.php and .inc files, database field values like enum types) maintaining the current structure of Timesheet 1.5.2. This work is almost finished. Also, I made small changes to the display of some pages. So, I can contribute to the diffusion of Timeshheet Next Gen in French. Best regards. Isabelle. |
From: Scott M. <sco...@gm...> - 2011-02-24 15:54:35
|
Isabelle, Thank you for your interest and work. There have been a few people who have expressed interest in making the system translatable, but I have not yet seen any work toward this goal. I am sure we could host your existing French version along side the current release, but I'm afraid that your work with the 1.5.2 version will be lost as we continue to move the system forward unless we modify the structure of TSNG to make translations into other languages much easier. There are a few of us currently working on the next potential version, the 2.0 demo branch, perhaps you could be persuaded to help us fix that version such that it would support translations? -Scott On Thu, Feb 24, 2011 at 2:15 PM, Isabelle Vergely <ver...@fr...>wrote: > Hello, > > I'm French. > > For my work, I identified Timesheet Next Gen 1.5.2 as a good open source > tool for recording the time spent on project tasks. > > Unfortunately, I quickly realized that its structure did not allow easily > to have versions with other languages than English. > I don't know if is planned a future version of Timesheet NG with a > structure that facilitates its use for non-English speaking users by > choosing the language and having different language files available. > > Whatever it is, I undertook the translation into French of the application > (.php and .inc files, database field values like enum types) maintaining the > current structure of Timesheet 1.5.2. This work is almost finished. > Also, I made small changes to the display of some pages. > > So, I can contribute to the diffusion of Timeshheet Next Gen in French. > > Best regards. > > Isabelle. > > > > ------------------------------------------------------------------------------ > Free Software Download: Index, Search & Analyze Logs and other IT data in > Real-Time with Splunk. Collect, index and harness all the fast moving IT > data > generated by your applications, servers and devices whether physical, > virtual > or in the cloud. Deliver compliance at lower cost and gain new business > insights. http://p.sf.net/sfu/splunk-dev2dev > _______________________________________________ > Tsheetx-developers mailing list > Tsh...@li... > https://lists.sourceforge.net/lists/listinfo/tsheetx-developers > > |
From: David T. <tom...@us...> - 2011-02-24 15:41:42
|
We have had a couple of people suggesting a translation, but you are the first to "produce the goods". Well done. The only question is how to sensibly integrate it. It comes under I18N problems. In the past we looked at php.gettext which would be relatively easy to use (especially that you have found all the text places to change - by translating them in place), but it depends a bit on your server setup. To be flexible, in the long term, my feeling is that it will need a user config field to define each user's locale, but you are probably OK with the global locale setting. Would you be able to contribute your changes as a developer? We would welcome any help you can give. Cheers tommo Date: Thu, 24 Feb 2011 15:15:05 +0100 From: ver...@fr... To: tsh...@li... Subject: [Tsheetx-developers] Proposal of contribution for a French version Hello, I'm French. For my work, I identified Timesheet Next Gen 1.5.2 as a good open source tool for recording the time spent on project tasks. Unfortunately, I quickly realized that its structure did not allow easily to have versions with other languages than English. I don't know if is planned a future version of Timesheet NG with a structure that facilitates its use for non-English speaking users by choosing the language and having different language files available. Whatever it is, I undertook the translation into French of the application (.php and .inc files, database field values like enum types) maintaining the current structure of Timesheet 1.5.2. This work is almost finished. Also, I made small changes to the display of some pages. So, I can contribute to the diffusion of Timeshheet Next Gen in French. Best regards. Isabelle. |
From: Isabelle V. <ver...@fr...> - 2011-02-24 14:15:21
|
Hello, I'm French. For my work, I identified Timesheet Next Gen 1.5.2 as a good open source tool for recording the time spent on project tasks. Unfortunately, I quickly realized that its structure did not allow easily to have versions with other languages than English. I don't know if is planned a future version of Timesheet NG with a structure that facilitates its use for non-English speaking users by choosing the language and having different language files available. Whatever it is, I undertook the translation into French of the application (.php and .inc files, database field values like enum types) maintaining the current structure of Timesheet 1.5.2. This work is almost finished. Also, I made small changes to the display of some pages. So, I can contribute to the diffusion of Timeshheet Next Gen in French. Best regards. Isabelle. |
From: David T. <tom...@us...> - 2011-02-23 16:55:02
|
I think we had this discussion before (regarding the timezone/locale functions). "Whatever version is in the latest Ubuntu" seemed to be the best bet. Anyone know? Date: Wed, 23 Feb 2011 14:56:13 +0000 From: sco...@gm... To: ma...@rw...; tsh...@li... Subject: Re: [Tsheetx-developers] php 5.1.6 - json_encode function doesn't exist Ah, yes, adding some if function exists stuff would be perfect; and I agree with 5.1+ being a valid target. -Scott On Wed, Feb 23, 2011 at 11:45 AM, Mark Wrightson <ma...@rw...> wrote: At the moment I am working on php 5.3.2 but my hosting company is: Centos, i686, Cpanel, php 5.2.9 I don't see any reason why we can't say php 5.1+ and make sure the code works. The error_get_last bit is only there to report a fatal error to the screen in a formatted way (and logged in the future) Some if(function_exists())) could be added for backwards compatibility. Similarly with json_encode either we can package the pear files into our software or just use the version in the snipplr link below. Mark _____________________________________________ Mob: 07725 695178 Email: ma...@rw... On 23/02/2011 06:27, Scott Miller wrote: Ah, wow, I'd thought the error thing may have been an over site, something forgotten. I didn't realize how many new features had been added to php. Relying on the newest and greatest functions, while fun, usually means that many will be unable to use that version for about, oh, two years is my guess. Whenever Centos/Redhat offer php5.2 as part of the base system, and then add about 18 months for the powers that be in semi-conservative shops to allow wholesale upgrading of systems. Really conservative shops may still be running redhat 7... Course all my conjecture is linux based; my world so to speak. So, do we, as developers, need to use this new functionality now, or can we plan to use it, but use whatever the old system used to do whatever function the new stuff now does until the world catches up a little? Regarding json, I'd read up enough to get it installed via pear on my centos system, so, I'm able to test the system more... I'm heading to bed; have a good morning, I'll be emailing you again probably mid afternoon your time :-) -Scott On Tue, Feb 22, 2011 at 8:59 PM, Mark Wrightson <ma...@rw...> wrote: This may also worthwhile looking at: http://snipplr.com/view/4964/emulate-php-5-for-backwards-compatibility/ _____________________________________________ Mob: 07725 695178 Email: ma...@rw... On 22/02/2011 20:39, Scott Miller wrote: I've got other issues with the 2.0 demo too. I don't have the newest php versions, so json is not part of the default php installation. Is the functionality provided by json_encode within the client_proj_task_javascript files the only way to do whatever it is doing? (I haven't yet attempted to dig into it) If not, can we provide another way for those with older PHP installations? -Scott ------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev _______________________________________________ Tsheetx-developers mailing list Tsh...@li... https://lists.sourceforge.net/lists/listinfo/tsheetx-developers ------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev _______________________________________________ Tsheetx-developers mailing list Tsh...@li... https://lists.sourceforge.net/lists/listinfo/tsheetx-developers ------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev _______________________________________________ Tsheetx-developers mailing list Tsh...@li... https://lists.sourceforge.net/lists/listinfo/tsheetx-developers |
From: Scott M. <sco...@gm...> - 2011-02-23 14:56:55
|
Ah, yes, adding some if function exists stuff would be perfect; and I agree with 5.1+ being a valid target. -Scott On Wed, Feb 23, 2011 at 11:45 AM, Mark Wrightson <ma...@rw...>wrote: > At the moment I am working on php 5.3.2 but my hosting company is: > Centos, i686, Cpanel, php 5.2.9 > I don't see any reason why we can't say php 5.1+ and make sure the code > works. > The error_get_last bit is only there to report a fatal error to the screen > in a formatted way (and logged in the future) > Some if(function_exists())) could be added for backwards compatibility. > Similarly with json_encode either we can package the pear files into our > software or just use the version in the snipplr link below. > > Mark > > _____________________________________________ > > Mob: 07725 695178 > Email: ma...@rw... > > > On 23/02/2011 06:27, Scott Miller wrote: > > Ah, wow, I'd thought the error thing may have been an over site, something > forgotten. I didn't realize how many new features had been added to php. > Relying on the newest and greatest functions, while fun, usually means that > many will be unable to use that version for about, oh, two years is my > guess. Whenever Centos/Redhat offer php5.2 as part of the base system, and > then add about 18 months for the powers that be in semi-conservative shops > to allow wholesale upgrading of systems. Really conservative shops may still > be running redhat 7... Course all my conjecture is linux based; my world so > to speak. > > So, do we, as developers, need to use this new functionality now, or can we > plan to use it, but use whatever the old system used to do whatever function > the new stuff now does until the world catches up a little? > > Regarding json, I'd read up enough to get it installed via pear on my > centos system, so, I'm able to test the system more... > > I'm heading to bed; have a good morning, I'll be emailing you again > probably mid afternoon your time :-) > > -Scott > > On Tue, Feb 22, 2011 at 8:59 PM, Mark Wrightson <ma...@rw...>wrote: > >> This may also worthwhile looking at: >> >> http://snipplr.com/view/4964/emulate-php-5-for-backwards-compatibility/ >> >> _____________________________________________ >> >> Mob: 07725 695178 >> Email: ma...@rw... >> >> >> On 22/02/2011 20:39, Scott Miller wrote: >> >> I've got other issues with the 2.0 demo too. I don't have the newest >> php versions, so json is not part of the default php installation. >> >> Is the functionality provided by json_encode within the >> client_proj_task_javascript files the only way to do whatever it is doing? >> (I haven't yet attempted to dig into it) >> >> If not, can we provide another way for those with older PHP installations? >> >> -Scott >> >> >> ------------------------------------------------------------------------------ >> Free Software Download: Index, Search & Analyze Logs and other IT data in >> Real-Time with Splunk. Collect, index and harness all the fast moving IT data >> generated by your applications, servers and devices whether physical, virtual >> or in the cloud. Deliver compliance at lower cost and gain new business >> insights. http://p.sf.net/sfu/splunk-dev2dev >> >> >> _______________________________________________ >> Tsheetx-developers mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/tsheetx-developers >> >> >> >> ------------------------------------------------------------------------------ >> Free Software Download: Index, Search & Analyze Logs and other IT data in >> Real-Time with Splunk. Collect, index and harness all the fast moving IT >> data >> generated by your applications, servers and devices whether physical, >> virtual >> or in the cloud. Deliver compliance at lower cost and gain new business >> insights. http://p.sf.net/sfu/splunk-dev2dev >> _______________________________________________ >> Tsheetx-developers mailing list >> Tsh...@li... >> https://lists.sourceforge.net/lists/listinfo/tsheetx-developers >> >> > |
From: Mark W. <ma...@rw...> - 2011-02-23 02:59:19
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> <title></title> </head> <body text="#000000" bgcolor="#ffffff"> This may also worthwhile looking at:<br> <br> <a class="moz-txt-link-freetext" href="http://snipplr.com/view/4964/emulate-php-5-for-backwards-compatibility/">http://snipplr.com/view/4964/emulate-php-5-for-backwards-compatibility/</a><br> <pre class="moz-signature" cols="72">_____________________________________________ Mob: 07725 695178 Email: <a class="moz-txt-link-abbreviated" href="mailto:ma...@rw...">ma...@rw...</a></pre> <br> On 22/02/2011 20:39, Scott Miller wrote: <blockquote cite="mid:AANLkTimvDBN=T4E...@ma..." type="cite">I've got other issues with the 2.0 demo too. I don't have the newest php versions, so json is not part of the default php installation.<br> <br> Is the functionality provided by json_encode within the client_proj_task_javascript files the only way to do whatever it is doing? (I haven't yet attempted to dig into it)<br> <br> If not, can we provide another way for those with older PHP installations?<br> <br> -Scott<br> <pre wrap=""> <fieldset class="mimeAttachmentHeader"></fieldset> ------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. <a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/splunk-dev2dev">http://p.sf.net/sfu/splunk-dev2dev</a> </pre> <pre wrap=""> <fieldset class="mimeAttachmentHeader"></fieldset> _______________________________________________ Tsheetx-developers mailing list <a class="moz-txt-link-abbreviated" href="mailto:Tsh...@li...">Tsh...@li...</a> <a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/tsheetx-developers">https://lists.sourceforge.net/lists/listinfo/tsheetx-developers</a> </pre> </blockquote> </body> </html> |
From: Mark W. <ma...@rw...> - 2011-02-23 02:35:44
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#ffffff"> Hmmm<br> <br> Javascript Object Notation (JSON) is a really powerful way of moving data from php to javascript and back again.<br> <br> I hadn't realised it was also relatively new. I googled it and came across this:<br> <br> <a class="moz-txt-link-freetext" href="http://www.epigroove.com/posts/97/how_to_use_json_in_php_4_or_php_51x">http://www.epigroove.com/posts/97/how_to_use_json_in_php_4_or_php_51x</a><br> <br> Mark<br> <pre class="moz-signature" cols="72">_____________________________________________ Mob: 07725 695178 Email: <a class="moz-txt-link-abbreviated" href="mailto:ma...@rw...">ma...@rw...</a></pre> <br> On 22/02/2011 20:39, Scott Miller wrote: <blockquote cite="mid:AANLkTimvDBN=T4E...@ma..." type="cite">I've got other issues with the 2.0 demo too. I don't have the newest php versions, so json is not part of the default php installation.<br> <br> Is the functionality provided by json_encode within the client_proj_task_javascript files the only way to do whatever it is doing? (I haven't yet attempted to dig into it)<br> <br> If not, can we provide another way for those with older PHP installations?<br> <br> -Scott<br> <pre wrap=""> <fieldset class="mimeAttachmentHeader"></fieldset> ------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. <a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/splunk-dev2dev">http://p.sf.net/sfu/splunk-dev2dev</a> </pre> <pre wrap=""> <fieldset class="mimeAttachmentHeader"></fieldset> _______________________________________________ Tsheetx-developers mailing list <a class="moz-txt-link-abbreviated" href="mailto:Tsh...@li...">Tsh...@li...</a> <a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/tsheetx-developers">https://lists.sourceforge.net/lists/listinfo/tsheetx-developers</a> </pre> </blockquote> </body> </html> |
From: Mark W. <ma...@rw...> - 2011-02-23 02:32:50
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#ffffff"> Ah, this is a php function that is newish. >5.2.0<br> <br> <a class="moz-txt-link-freetext" href="http://php.net/manual/en/function.error-get-last.php">http://php.net/manual/en/function.error-get-last.php</a><br> <pre class="moz-signature" cols="72">_____________________________________________ Mob: 07725 695178 Email: <a class="moz-txt-link-abbreviated" href="mailto:ma...@rw...">ma...@rw...</a></pre> <br> On 22/02/2011 20:31, Scott Miller wrote: <blockquote cite="mid:AAN...@ma..." type="cite">Hey all,<br> <br> I'm seeing many "Call to undefined function error_get_last()" errors in the error log. One example of the message in its entirety: <br> <br> <span style="font-family: courier new,monospace;">[Tue Feb 22 14:24:08 2011] [error] [client 10.110.1.142] PHP Fatal error: Call to undefined function error_get_last() in /var/websites/development/timesheet/apps/ts20/content/include/error_handler.php on line 190</span><br> <br> I'm not able to find an instance of this function, and I just wanted to make sure someone was aware and planning to fill in this hole.<br> <br> -Scott<br> </blockquote> </body> </html> |
From: Scott M. <sco...@gm...> - 2011-02-22 20:40:54
|
I've got other issues with the 2.0 demo too. I don't have the newest php versions, so json is not part of the default php installation. Is the functionality provided by json_encode within the client_proj_task_javascript files the only way to do whatever it is doing? (I haven't yet attempted to dig into it) If not, can we provide another way for those with older PHP installations? -Scott |
From: Scott M. <sco...@gm...> - 2011-02-22 20:32:06
|
Hey all, I'm seeing many "Call to undefined function error_get_last()" errors in the error log. One example of the message in its entirety: [Tue Feb 22 14:24:08 2011] [error] [client 10.110.1.142] PHP Fatal error: Call to undefined function error_get_last() in /var/websites/development/timesheet/apps/ts20/content/include/error_handler.php on line 190 I'm not able to find an instance of this function, and I just wanted to make sure someone was aware and planning to fill in this hole. -Scott |
From: Scott M. <sco...@gm...> - 2011-02-22 19:13:15
|
Ok, my work on 2.0 demo has just been checked in; the only places left that deal with the original database_credentials file are the new config.php file, and the old and new installation areas (they haven't been "fixed" yet). -Scott On Tue, Feb 22, 2011 at 6:49 PM, Scott Miller <sco...@gm...>wrote: > Well, I'd been just commenting the unneeded > include(database_credentials.inc) and include(table_names.inc) pieces out, > but yeah, deleting them once I've proven to myself they weren't needed any > more is probably the right thing to do. > > I haven't touched much (anything?) that included the html stuff, so, I > haven't had a chance to remove any of that. > > Aside from what we've been removing from the global variables area > (configs, table names), I'm not sure which other items are left. The > siteclosed stuff was a hasty add by me when I needed to upgrade our > production system, so, improve away :-) > > -Scott > > > > On Tue, Feb 22, 2011 at 5:10 PM, Mark Wrightson <ma...@rw...>wrote: > >> Hi Scott, >> >> There shouldn't be any references left to database_credentials other than >> in config.php. I dont think we should remove the database_credentials file >> until the new installer / upgrader is finished. The file mysql.db.inc is >> now redundant (almost). There is a new database class in the include >> directory that handles all of the db stuff. >> >> Oops - I thought i had got rid of all of the non OO references to tables! >> >> There is one section that still needs looking at and that is global >> variables. Global variables just don't work in the new system (which is >> good news! as they are horrible) However there are still some references to >> them that haven't been corrected. >> >> With reference to the siteClosed stuff. I am intending to update all of >> the login / logout / forgotpass stuff and that will include updating >> siteclosed. Im mentioning it here as there is some global references to >> siteclosed. >> >> The HTML stuff from config is not used anywhere anymore (at least it >> shouldn't be) Feel free to start removing it! >> What is the reason for not being able to move the ACL pieces just yet? >> >> It sounds like you've got quite a lot done. Good Work! >> I wish i had more time available to help out. >> >> >> Mark >> >> _____________________________________________ >> >> Mob: 07725 695178 >> Email: ma...@rw... >> >> >> On 22/02/2011 15:04, Scott Miller wrote: >> >> Hey Mark, >> >> I'm getting ready to check my work in, I believe your new config.php file >> is the way to go, so, I'm going to make an attempt to remove all reference >> to the database_credentials.inc file in the code, except for the install >> part, that will happen later. I've removed the non-OO table references in >> the class.AuthenticationManager.php, and changed that file to grab the LDAP >> configuration from the new configuration table, and I'm loading those >> variables in my OO associative array. >> >> I would like to eliminate any usage of the old config table except for the >> the HTML and ACL (security) pieces for now. The long term plan should be to >> remove the old table entirely, but we need to take smallish steps to get >> there :-) >> >> Feed back on my install stuff email or any of this stuff would be >> appreciated... >> >> -Scott >> >> On Mon, Feb 21, 2011 at 5:08 PM, Scott Miller <sco...@gm...>wrote: >> >>> Hey Mark, >>> >>> To quickly be able to test my upgrade script, I had to take the old >>> install directory structure and placed it into a directory called oldinstall >>> off the root context directory. For what I've done thus far, it worked >>> great. So, I think we've got the ability to allow the old upgrade/install >>> stuff to continue to function, we just have to direct people to have their >>> browser open the oldinstall/index.php page, or we could put a link in your >>> new install functionality too. But, we can continue working on a new >>> install methodology at the same time too. Eventually the oldinstall >>> directory will just disappear when the new stuff is done. >>> >>> -Scott >>> >>> >>> |
From: Scott M. <sco...@gm...> - 2011-02-21 17:10:56
|
Hey Mark, To quickly be able to test my upgrade script, I had to take the old install directory structure and placed it into a directory called oldinstall off the root context directory. For what I've done thus far, it worked great. So, I think we've got the ability to allow the old upgrade/install stuff to continue to function, we just have to direct people to have their browser open the oldinstall/index.php page, or we could put a link in your new install functionality too. But, we can continue working on a new install methodology at the same time too. Eventually the oldinstall directory will just disappear when the new stuff is done. -Scott On Mon, Feb 21, 2011 at 3:11 PM, Scott Miller <sco...@gm...>wrote: > Oh, we'd probably want to rename the file to something other than > version.php. Maybe buildnumber.php? > > -Scott > > > On Mon, Feb 21, 2011 at 3:09 PM, Scott Miller <sco...@gm...>wrote: > >> Actually, the first answer from that link is probably what should be >> used. The version.php file should be ignored (thus never checked in), but >> the file could be generated by the developers automatically, or as they (we) >> saw fit. But it would have to be re-generated and included in all public >> releases. >> >> ----------------------------------------------- >> Abbreviated answer pasted here: >> >> Wherever I need the revision I do an include: <?php include >> 'version.php'; ?>. This "version.php" file only has the revision number. >> Moreover it is not part of the repository (it set to be ignored). Here is >> how I create it: >> >> 1) On projects where SVN is installed on the server, I also use it for >> deployment. Getting the latest version to the server I have a script that >> among other things does the following (it runs on the server): >> >> cd /var/www/project >> >> svn update >> rm version.php >> svnversion > version.php >> >> ----------------------------------------------- >> >> I've always regarded cross compiling as a bit of magic; never had any >> needs to do any of that myself. >> >> -Scott >> >> >> On Mon, Feb 21, 2011 at 1:09 PM, Mark Wrightson <ma...@rw... >> > wrote: >> >>> Ive had a look at how you can do the build number properly and it isn't >>> particularly easy. You start to need subversion binaries bundled in with >>> the code or to have a makefile build process. >>> >>> >>> http://stackoverflow.com/questions/111436/how-can-i-get-the-svn-revision-number-in-php >>> >>> I think while it would be nice to have, it will quickly become a bit of a >>> nightmare due to ensuring compatibility with windows / nix etc. I started a >>> mini project to get subversion running on a >>> commercial hosting companies servers but never got it finished as I ran >>> out of expertise in the linux cross compiling department. The plan was to >>> write a script that allowed a site to update >>> automatically through the svn checkout process. >>> >>> mark >>> >>> _____________________________________________ >>> >>> Mob: 07725 695178 >>> Email: ma...@rw... >>> >>> >>> On 21/02/2011 01:27, Scott Miller wrote: >>> >>> Well, knowing the build number is helpful in two occasions that I can >>> come up with quickly: During development, if you're testing different >>> versions of the same general build (trunk, or 2.0) between real "versions", >>> you'd be able to tell the difference between the two. And if the version >>> numbers get messed up sometime in the future when new releases are created, >>> we'd be able to figure out which versions were actually newer than the >>> others a bit easier than we might otherwise be able. >>> >>> I'm thinking if/when we do need serialized objects, we can modify the >>> schema at that point... >>> >>> -Scott >>> >>> On Sun, Feb 20, 2011 at 6:25 PM, Mark Wrightson < >>> ma...@rw...> wrote: >>> >>>> Scott, >>>> >>>> What would the benefit of having a build number actually be? Do we have >>>> a need for one? The difficulty arises that you can get the version number >>>> of an individual file and subversion will save the version number in a >>>> predefined location in the code but this number would only be correct if >>>> that one file was committed & changed every single time. >>>> >>>> I can't think of any reason to use serialised objects at the moment i >>>> just thought there may be a use one day. Ok leave it as tinytext, i'm sure >>>> that'll be fine. >>>> >>>> >>>> Regards >>>> Mark Wrightson >>>> >>>> _____________________________________________ >>>> >>>> Mob: 07725 695178 >>>> Email: ma...@rw... >>>> >>>> >>>> On 20/02/2011 20:25, Scott Miller wrote: >>>> >>>> I agree we don't want the svn revision number as part of the version, >>>> but I do like having it visible. I use fwbuilder, and it, and many other >>>> products I can't necessarily remember at the moment, they have a version >>>> number and a separate "build" number that is very likely an svn type >>>> revision number; perhaps we can use something like that? >>>> >>>> What kinds of things can you envision being stored as serialised >>>> objects? Currently I'm running with a version for the new configuration >>>> table that will use tinytext as the value field type, but this can easily be >>>> changed at the moment... >>>> >>>> Thanks for the "blue print"... >>>> >>>> -Scott >>>> >>>> On Sun, Feb 20, 2011 at 12:40 PM, Mark Wrightson < >>>> ma...@rw...> wrote: >>>> >>>>> I dont particularly think svn revision numbers are a good way of >>>>> controlling the actual version of the application. because a single change >>>>> to the trunk should not constitute a requirement to run update scripts to >>>>> modify the database etc. >>>>> >>>>> Maybe it should be just a text field? it doesn't really make much >>>>> difference though does it? I'm thinking that in future we may end up >>>>> storing serialised objects in the database and it may quite easily get >>>>> larger than 255 chars. Or should we just use tinytext? I personally have >>>>> no preference. 255 chars would probably be fine. >>>>> >>>>> >>>>> The way the installer works is: >>>>> >>>>> site.class.php: >>>>> >>>>> 1. init config >>>>> 2. connect to database >>>>> If the connection to the db fails then check the config::isInstalled >>>>> variable. >>>>> If it is installed then show an error page, if it is not installed goto >>>>> the page install.php?page=install >>>>> >>>>> Assuming the site is installed and the database connects ok >>>>> Config::getDbConfig() is called to grab the data out of the new config >>>>> database table. >>>>> Inside this function it the calls runVersionCheck() which compares the >>>>> version grabbed from the database to the value of ConfigFactory::$version >>>>> If the versions do not match then goto the page >>>>> install.php?page=upgrade >>>>> >>>>> By redirecting to install.php, the usual path of the site loading >>>>> through index.php doesn't apply. the install.php file loads the >>>>> install.site.class.php instead of site.class.php >>>>> which is slightly different. >>>>> >>>>> Cheers >>>>> >>>>> >>>>> Mark Wrightson >>>>> >>>>> _____________________________________________ >>>>> >>>>> Mob: 07725 695178 >>>>> Email: ma...@rw... >>>>> >>>>> >>>>> On 18/02/2011 23:32, Scott Miller wrote: >>>>> >>>>> Mark, can you give me a brief outline of how the system figures out if >>>>> it needs to upgrade itself? I think I'm done with the sql stuff, but need >>>>> to test it, and want to know what calls what. >>>>> >>>>> I'd start figuring it out on my own, but I need to head out for the >>>>> weekend myself, hopefully you'll have responded by the time I get in Morning >>>>> :-) >>>>> >>>>> -Scott >>>>> >>>>> |