Tyron, the messages in the rules are not translatable using our standard gettext mechanism?
On Sat, Aug 6, 2011 at 1:59 PM, Marc Delisle marc@infomarc.info wrote:
Tyron, the messages in the rules are not translatable using our standard gettext mechanism?
Yes, that is an issue that I still have to solve. I'd love to keep the rules file independent from the translation mechanism by adding some compile/transform mechanism for pma releases.
But if that is not possible I guess I will have to rename advisory_rules.txt to a php file, surround all text strings with __(' '); and hope it works as well.
I'd prefer to have the syntax of advsiory_rules.txt as simple as possible so other users can easily add new rules without the knowledge of php.
What do you think would be the best choice what to do?
-- Marc Delisle http://infomarc.info
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
2011/8/6 Tyron Madlener tyronx@gmail.com:
On Sat, Aug 6, 2011 at 1:59 PM, Marc Delisle marc@infomarc.info wrote:
Tyron, the messages in the rules are not translatable using our standard gettext mechanism?
Yes, that is an issue that I still have to solve. I'd love to keep the rules file independent from the translation mechanism by adding some compile/transform mechanism for pma releases.
But if that is not possible I guess I will have to rename advisory_rules.txt to a php file, surround all text strings with __(' '); and hope it works as well.
I'd prefer to have the syntax of advsiory_rules.txt as simple as possible so other users can easily add new rules without the knowledge of php.
What do you think would be the best choice what to do?
How about using arrays? Yes, it requires at least enough knowledge of PHP so as not to break strings, but I believe no one without such knowledge would want to modify it anyway.
Le 2011-08-06 15:22, Piotr Przybylski a écrit :
2011/8/6 Tyron Madlener tyronx@gmail.com:
On Sat, Aug 6, 2011 at 1:59 PM, Marc Delisle marc@infomarc.info wrote:
Tyron, the messages in the rules are not translatable using our standard gettext mechanism?
Yes, that is an issue that I still have to solve. I'd love to keep the rules file independent from the translation mechanism by adding some compile/transform mechanism for pma releases.
But if that is not possible I guess I will have to rename advisory_rules.txt to a php file, surround all text strings with __(' '); and hope it works as well.
I'd prefer to have the syntax of advsiory_rules.txt as simple as possible so other users can easily add new rules without the knowledge of php.
What do you think would be the best choice what to do?
How about using arrays? Yes, it requires at least enough knowledge of PHP so as not to break strings, but I believe no one without such knowledge would want to modify it anyway.
I agree with Piotr. Also, having this rule parser in the code base means more code to maintain. Finally, I believe that using a syntax similar to the one of libraries/export/sql.php will bring better readability for the rules.
Hi
Dne Sat, 6 Aug 2011 21:49:56 +0300 Tyron Madlener tyronx@gmail.com napsal(a):
Yes, that is an issue that I still have to solve. I'd love to keep the rules file independent from the translation mechanism by adding some compile/transform mechanism for pma releases.
But if that is not possible I guess I will have to rename advisory_rules.txt to a php file, surround all text strings with __(' '); and hope it works as well.
I'd prefer to have the syntax of advsiory_rules.txt as simple as possible so other users can easily add new rules without the knowledge of php.
What I don't like about text file solution is that it brings need to maintain parser for that. Having the data as PHP array would avoid this and I think it could be as readable as the text file is. I would see great advantage of text file if it could be shared with other tools, what I don't think it is the case right now. Being only for phpMyAdmin, I'd stick with PHP code.
On the other side, translation could be solved for text file as well, if we decide to use it.
On Mon, Aug 8, 2011 at 10:34 AM, Michal Čihař michal@cihar.com wrote:
Hi
Dne Sat, 6 Aug 2011 21:49:56 +0300 Tyron Madlener tyronx@gmail.com napsal(a):
Yes, that is an issue that I still have to solve. I'd love to keep the rules file independent from the translation mechanism by adding some compile/transform mechanism for pma releases.
But if that is not possible I guess I will have to rename advisory_rules.txt to a php file, surround all text strings with __(' '); and hope it works as well.
I'd prefer to have the syntax of advsiory_rules.txt as simple as possible so other users can easily add new rules without the knowledge of php.
What I don't like about text file solution is that it brings need to maintain parser for that. Having the data as PHP array would avoid this and I think it could be as readable as the text file is. I would see great advantage of text file if it could be shared with other tools, what I don't think it is the case right now. Being only for phpMyAdmin, I'd stick with PHP code.
On the other side, translation could be solved for text file as well, if we decide to use it.
Some arguments for a independent file formatted are narrated by a comment from Sheeri here: https://answers.launchpad.net/mysqltuner/+question/166442
I would see great advantage of text file if it could be shared with other tools, what I don't think it is the case right now.
Indeed, I chose the format this way, in the hope for it to be used with other tools as well. Maybe I am being a bit too visionary there. However, quite naturally, a new file format will be used by only one tool in the beginning ;-) It is also possible to build the rules file more independent (e.g. remove preg_match() calls), to guarantee the interchangeability.
I agree with Piotr. Also, having this rule parser in the code base means
more code to maintain.
The rule parser itself is only around 80 lines of code. For php arrays it would also require some lines of code to verify if the elements in the array are in the correct format.
Unfortunately it is hard to estimate the gain and loss when using php arrays instead of a (mostly) independent syntax, since we don't know how this will develop in the future.
If translation of the text file is possible with not too much efforts, I still would vote for that solution. However, if I am the only one with that opinion I will bend to the opinion of the majority ;-)
-- Michal Čihař | http://cihar.com | http://blog.cihar.com
Hi
Dne Mon, 8 Aug 2011 11:47:20 +0300 Tyron Madlener tyronx@gmail.com napsal(a):
Indeed, I chose the format this way, in the hope for it to be used with other tools as well. Maybe I am being a bit too visionary there. However, quite naturally, a new file format will be used by only one tool in the beginning ;-) It is also possible to build the rules file more independent (e.g. remove preg_match() calls), to guarantee the interchangeability.
Using things like PMA_timespanFormat, PMA_bytime or PMA_DRIZZLE does not make it really portable :-).
If translation of the text file is possible with not too much efforts, I still would vote for that solution. However, if I am the only one with that opinion I will bend to the opinion of the majority ;-)
Translation for rules is now ready to be used in master, we can always switch to php array based solution if this turns out to be too complicated.
resending to list...
On Thu, Aug 11, 2011 at 3:02 PM, Michal Čihař michal@cihar.com wrote:
Hi
Dne Mon, 8 Aug 2011 11:47:20 +0300 Tyron Madlener tyronx@gmail.com napsal(a):
Indeed, I chose the format this way, in the hope for it to be used with other tools as well. Maybe I am being a bit too visionary there. However, quite naturally, a new file format will be used by only one tool in the beginning ;-) It is also possible to build the rules file more independent (e.g. remove preg_match() calls), to guarantee the interchangeability.
Using things like PMA_timespanFormat, PMA_bytime or PMA_DRIZZLE does not make it really portable :-).
Yes indeed. I would to find away around this. PMA_bytime however should be ok - its defined in advisor.class.php. I could rename them all to something neutral and then define wrapper functions in advsior.class.php.
So as an example in advisory_rules.txt I use timespanFormat(...) and place something like this in advisor.class.php function timespanFormat($num) { return PMA_timespanFormat($num); }
I guess that would be the prettiest solution.
If translation of the text file is possible with not too much efforts, I still would vote for that solution. However, if I am the only one with that opinion I will bend to the opinion of the majority ;-)
Translation for rules is now ready to be used in master, we can always switch to php array based solution if this turns out to be too complicated.
Thanks :)
-- Michal Čihař | http://cihar.com | http://blog.cihar.com
-
Marc Delisle -
Michal Čihař -
Piotr Przybylski -
Tyron Madlener