Re: [PHP-DOC] [PATCH] rtl...
What is the status of RTL support in livedocs? Goba moshe doron rta: you correction is mistake. RTL and CHARSET are defines not vars at all. --/moshe Nuno Lopes [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Moshe, as I've already told you, your patch had a little bug with GLOBALS. Attached is a correction for your patch. Nuno - Original Message - Wez Furlong [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Now, quit complaining and get coding ;-) --Wez. http://moshe.i-com-it.com/patchs/livedocs-rtl3.patch.txt this patch contains: 1. initial rtl support. 2. add some missing htmlspecialchars(). i change the htmlentities(); on pre into htmlspecialchars() coz htmlentities(); doesn't fit well for not english charsets, do i miss something? --/moshe
Re: [PHP-DOC] [PATCH] rtl...
i didn't followed the last livedocs patchs but the last time i test it, after the rtl stuff was commited, its just worked fine. Moshe. Gabor Hojtsy [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] What is the status of RTL support in livedocs? Goba moshe doron rta: you correction is mistake. RTL and CHARSET are defines not vars at all. --/moshe Nuno Lopes [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Moshe, as I've already told you, your patch had a little bug with GLOBALS. Attached is a correction for your patch. Nuno - Original Message - Wez Furlong [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Now, quit complaining and get coding ;-) --Wez. http://moshe.i-com-it.com/patchs/livedocs-rtl3.patch.txt this patch contains: 1. initial rtl support. 2. add some missing htmlspecialchars(). i change the htmlentities(); on pre into htmlspecialchars() coz htmlentities(); doesn't fit well for not english charsets, do i miss something? --/moshe
Re: [PHP-DOC] [PATCH] rtl...
i didn't followed the last livedocs patchs but the last time i test it, after the rtl stuff was commited, its just worked fine. Great, so then I can just pull off my unread mails from that TODO list :) Goba
[PHP-DOC] [PATCH] rtl...
Wez Furlong [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Now, quit complaining and get coding ;-) --Wez. http://moshe.i-com-it.com/patchs/livedocs-rtl3.patch.txt this patch contains: 1. initial rtl support. 2. add some missing htmlspecialchars(). i change the htmlentities(); on pre into htmlspecialchars() coz htmlentities(); doesn't fit well for not english charsets, do i miss something? --/moshe
Re: [PHP-DOC] [PATCH] rtl...
Moshe, as I've already told you, your patch had a little bug with GLOBALS.
Attached is a correction for your patch.
Nuno
- Original Message -
Wez Furlong [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Now, quit complaining and get coding ;-)
--Wez.
http://moshe.i-com-it.com/patchs/livedocs-rtl3.patch.txt
this patch contains:
1. initial rtl support.
2. add some missing htmlspecialchars().
i change the htmlentities(); on pre into htmlspecialchars() coz
htmlentities(); doesn't fit well for not english charsets, do i miss
something?
--/mosheIndex: common.php
===
RCS file: /repository/livedocs/common.php,v
retrieving revision 1.12
diff -u -r1.12 common.php
--- common.php 5 May 2004 01:37:03 - 1.12
+++ common.php 5 May 2004 17:33:36 -
@@ -83,5 +83,15 @@
$NOTESDB = false;
}
+$rtl_langs = array('he','ar');
+define('RTL', isset($rtl_langs[$lang])?1:0);
+
+
+/* TODO: add all languages here */
+$chars = array('ar' = 'ISO-8859-6',
+ 'he' = 'windows-1255',
+ 'ja' = 'UTF-8');
+
+define('CHARSET', isset($chars[$lang]) ? $chars[$lang] : 'iso-8859-1');
?
Index: style_mapping.php
===
RCS file: /repository/livedocs/style_mapping.php,v
retrieving revision 1.11
diff -u -r1.11 style_mapping.php
--- style_mapping.php 1 May 2004 11:34:50 - 1.11
+++ style_mapping.php 5 May 2004 17:33:36 -
@@ -150,7 +150,11 @@
}
}
- return sprintf('div class=copyrightCopyright copy; %s by %s/div',
implode(, , $y), $holder);
+ if(RTL) {
+ return sprintf('div dir=ltr class=copyrightCopyright copy; %s
by span dir=rtl%s/spannbsp;/div', implode(, , $y), $holder);
+ } else {
+ return sprintf('div class=copyrightCopyright copy; %s by
%s/div', implode(, , $y), $holder);
+ }
}
function format_refpurpose($node)
@@ -199,25 +203,28 @@
function format_parameter($node)
{
- return sprintf('span class=%s$%s/span', $node-tagname, $node-content);
+ return sprintf('span class=%s$%s/span', $node-tagname,
htmlspecialchars($node-content, ENT_NOQUOTES));
}
function format_pubdate($node)
{
- return sprintf('div class=%sPublished on: %s/div', $node-tagname,
$node-content);
+ return sprintf('div class=%sPublished on: %s/div', $node-tagname,
htmlspecialchars($node-content, ENT_NOQUOTES));
}
function format_ulink($node)
{
- return sprintf('a target=_blank class=ulink href=%s%s/a',
- $node-attributes['url'],
- $node-content
- );
+ $dir = (RTL !ereg(([à-ú]+),$node-content)) ? ' dir=ltr' : ;
+ return sprintf('a target=_blank class=ulink href=%s%s%s/a',
+ $node-attributes['url'],
+ $dir,
+ htmlspecialchars($node-content, ENT_NOQUOTES)
+ );
+
}
function format_warning_title($node)
{
- return sprintf('span class=warning_title%s/span', $node-content);
+ return sprintf('span class=warning_title%s/span',
htmlspecialchars($node-content, ENT_NOQUOTES));
}
function format_link($node)
@@ -232,11 +239,14 @@
$caption = $node-attributes['linkend'];
}
$url = generate_url_for_id($lang, $node-attributes['linkend']);
- return sprintf('a class=%s href=%s%s/a',
- $node-tagname,
- $url,
- $caption
- );
+ $dir = isset($node-attributes['dir']) ? ' dir='.$node-attributes['dir'].''
: '';
+
+ return sprintf('a class=%s href=%s%s%s/a',
+ $node-tagname,
+ $url,
+ $dir,
+ $caption
+ );
}
function format_function($node)
@@ -262,12 +272,18 @@
return sprintf('span class=%s%s()/span', $class, $node-content);
}
- $url = generate_url_for_id($lang, $dest);
- return sprintf('a class=%s href=%s%s()/a',
- $class,
- $url,
- $node-content
- );
+ $dir = RTL ? ' dir=ltr' : '';
+ if ($current_page == $dest) {
+ return sprintf('span class=%s%s%s()/span', $class, $dir,
$node-content);
+ }
+
+ $url = generate_url_for_id($lang, $dest);
+ return sprintf('a class=%s href=%s%s%s()/a',
+ $class,
+ $url,
+ $dir,
+ htmlspecialchars($node-content, ENT_NOQUOTES)
+ );
}
function format_listing($node)
@@ -315,13 +331,14 @@
case 'html':
case 'xml':
case 'c':
- $content = 'pre' . htmlentities($content) . '/pre';
+ $content = 'pre' . htmlspecialchars($content) . '/pre';
break;
default:
[PHP-DOC] [Spam 05.70] RE: [PHP-DOC] [PATCH] rtl...
This mail is probably spam. The original message has been attached
along with this report, so you can recognize or block similar unwanted
mail in future. See http://spamassassin.org/tag/ for more details.
Content preview: [this message may have been sent out twice; the
previous message has a bogus email address; my apologies] Thanks; looks
good, although I'd prefer it if we didn't have too many special cases
going on. [...]
Content analysis details: (5.70 points, 5 required)
NO_REAL_NAME (0.8 points) From: does not include a real name
IN_REP_TO (-0.5 points) Has a In-Reply-To header
HTML_00_10 (1.2 points) BODY: Message is 0% to 10% HTML
HTML_MESSAGE (0.1 points) BODY: HTML included in message
FORGED_MUA_OUTLOOK (3.5 points) Forged mail pretending to be from MS Outlook
MISSING_OUTLOOK_NAME (0.6 points) Message looks like Outlook, but isn't
---BeginMessage---
[this message may have been sent out twice; the previous message has a bogus
email address; my apologies]
Thanks; looks good, although I'd prefer it if we didn't have too many
special cases going on.
You have an RTL constant to indicate that the content is RTL, but then there
are a number of places where you use that to generate a dir=rtl attribute.
It would be better to define a DIRECTION constant that held dir=rtl or
dir=ltr as appropriate for the language, and use that unconditionally.
Likewise for the copyright text in style_mapping.php; just fold it into a
single line that includes the directionality in any case:
return sprintf('pDEFANGED_div dir=ltr class=copyrightCopyright copy; %s by
DEFANGED_span %s%s/DEFANGED_span/pDEFANGED_div', implode(, , $y), DIRECTION,
$holder);
The other thing I noticed was that you have:
$map['emphasis'] = 'format_emphasis';
but then:
function format_em($node) { ... }
--Wez.
-Original Message-
From: moshe doron [mailto:[EMAIL PROTECTED]
Sent: 05 May 2004 19:14
To: [EMAIL PROTECTED]
Subject: [PHP-DOC] [PATCH] rtl...
Wez Furlong [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Now, quit complaining and get coding ;-)
--Wez.
http://moshe.i-com-it.com/patchs/livedocs-rtl3.patch.txt
this patch contains:
1. initial rtl support.
2. add some missing htmlspecialchars().
i change the htmlentities(); on pre into htmlspecialchars() coz
htmlentities(); doesn't fit well for not english charsets, do i miss
something?
--/moshe
---End Message---
Re: [PHP-DOC] [PATCH] rtl...
you correction is mistake. RTL and CHARSET are defines not vars at all. --/moshe Nuno Lopes [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Moshe, as I've already told you, your patch had a little bug with GLOBALS. Attached is a correction for your patch. Nuno - Original Message - Wez Furlong [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Now, quit complaining and get coding ;-) --Wez. http://moshe.i-com-it.com/patchs/livedocs-rtl3.patch.txt this patch contains: 1. initial rtl support. 2. add some missing htmlspecialchars(). i change the htmlentities(); on pre into htmlspecialchars() coz htmlentities(); doesn't fit well for not english charsets, do i miss something? --/moshe
Re: [PHP-DOC] [PATCH] rtl...
OMG. using global $DEFINE is right! If you don't declare it as global, it won't work if register_globals is off (as you should have it! :) Nuno - Original Message - you correction is mistake. RTL and CHARSET are defines not vars at all. --/moshe
[PHP-DOC] Re: [Spam 05.70] RE: [PHP-DOC] [PATCH] rtl...
Thanks; looks good, although I'd prefer it if we didn't have too many
special cases going on.
You have an RTL constant to indicate that the content is RTL, but then
there
are a number of places where you use that to generate a dir=rtl
attribute.
It would be better to define a DIRECTION constant that held dir=rtl or
dir=ltr as appropriate for the language, and use that unconditionally.
i'll adopt the idea.
Likewise for the copyright text in style_mapping.php; just fold it into a
single line that includes the directionality in any case:
return sprintf('pDEFANGED_div dir=ltr class=copyrightCopyright
copy; %s by
DEFANGED_span %s%s/ DEFANGED_span/pDEFANGED_div', implode(, ,
$y), DIRECTION, $holder);
this line is anyway candidate to change due to the by that have to be
translated by into entity that reflect the translation (my preference btw,
is is one dictionary file per language to keep the livedocs core
independent).
this change 'll change this lumpy line logic - lets just i keep it simple
for now.
i touched this line just because i wanted that the manual cover looks
professional.
The other thing I noticed was that you have:
$map['emphasis'] = 'format_emphasis';
but then:
function format_em($node) { ... }
i'll fix it. it was lost on last model changing.
--Wez.
[PHP-DOC] Re: [Spam 05.70] RE: [PHP-DOC] [PATCH] rtl...
Moshe Doron [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Thanks; looks good, although I'd prefer it if we didn't have too many special cases going on. You have an RTL constant to indicate that the content is RTL, but then there are a number of places where you use that to generate a dir=rtl attribute. It would be better to define a DIRECTION constant that held dir=rtl or dir=ltr as appropriate for the language, and use that unconditionally. i'll adopt the idea. i didn't read you carfuly enough. on rtl mode we need times to dump dir=rtl and times dir=ltr on non-rtl languages we have no worries about this issue. my guideline is to leave the ltr document as it was before my plays. you never know how any browser behave after dir=ltr even if the it sensible that this instruction should have no effect. anyway i follow your line of thought and make the RTL hold the text. here the new patch: http://moshe.i-com-it.com/patchs/livedocs-rtl4.patch.txt --/moshe.
Re: [PHP-DOC] [PATCH] rtl...
On Wed, 5 May 2004, Nuno Lopes wrote: OMG. using global $DEFINE is right! If you don't declare it as global, it won't work if register_globals is off (as you should have it! :) $GLOBALS['key'] please, no global $key; Derick
[PHP-DOC] [PATCH] rtl second edition
here the 'all in one method': http://moshe.i-com-it.com/patchs/livedocs-rtl2.patch.txt rejections? --/moshe.
Re: [PHP-DOC] [PATCH] rtl second edition
I totally agree with it! Please commit it! Just a question: why do you use ENT_NOQUOTES in htmlspecialchars()? I think you have a little problem with globals, but commit the patch and then I correct it. Nuno - Original Message - From: moshe doron [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, May 04, 2004 10:43 AM Subject: [PHP-DOC] [PATCH] rtl second edition here the 'all in one method': http://moshe.i-com-it.com/patchs/livedocs-rtl2.patch.txt rejections? --/moshe.
Re: [PHP-DOC] [PATCH] rtl
Moshe Doron [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Nuno Lopes [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] The old build system is used when you run build.sh in livedocs. It does a ./configure --with-lang=$lang I don't know if we will ever get ride of this build system. The use of entities is a good idea, Goba! we may add the entites for livedocs in language-snippets.ent, for example. Moshe: There won't be too many IFs. We need just one if for the array $map and other IF to declare your special functions. No real impact on performance and its much more manageable. Anyway, any more opinions? i'm not realy care about this point. my initial intuition was to split the files but IFs also have gains. We need also to decide how to choose the encoding and how to choose if RTL or LTR for each language. Create an array with this info? It's dificult to extract this info from the old (actual) build system because livedocs can be used for more than one language. i'm +1 for array method. more feedbacks? goba, adding new i18n.php file that will hold the languages data is agreed? --/moshe.
Re: [PHP-DOC] [PATCH] rtl
We need also to decide how to choose the encoding and how to choose if RTL or LTR for each language. Create an array with this info? It's dificult to extract this info from the old (actual) build system because livedocs can be used for more than one language. i'm +1 for array method. more feedbacks? can i put the languages array in new i18n.php file? --/moshe.
Re: [PHP-DOC] [PATCH] rtl
I'm 100% with Gabor here. We should only focus on the rendering part now. The build system will remain the same for the moment. Moshe, can you please wait for an answer before commiting ? Next time, please propose the patch *before* commiting it, it will avoid us to commit, revert, re-commit and it will be more easy to keep an eyes on livedocs sources :) Thank you a lot for you efforts :) didou Gabor Hojtsy wrote: Are you planing to use on the old build system forever? Shouldn't livdocs replace completely the old system sometime? Livedocs is currently not aimed at replacing the complete build system. Livedocs itself needs command line tools to build the index and configure the system. It does not know that much about the built documentation, and it does not need to know that much. Livedocs was planned to be available for not only phpdoc but for other projects as well (smarty, peardoc and php-gtk are the next target beyond phpdoc). We are not planning to use the current build system forever, we don't have plans for the infinite future. Since we are not in a position to require PHP 5 to run livedocs (it needs to run on all PHP.net mirror sites and client machines as well), we cannot eliminate the need to use libxml2 and some command line tools to glue these together. The configure and make tools in the phpdoc build system do a lot to ensure that partial results are cached, and reused as possible. If we would employ a dumb PHP based build system, these advantages would be lost. There is no PHP based build system yet running with PHP 4.x.x AFAIK. also if the answers to those two questions are yes and no, Imho, the multi languages support on the old build is realy creak part (specially in the aspect of not duplication the code and files-structure) and and we sould reduce the old build system relay as much as possible. It's just looks to me stupid giving the new build system the pleasure to extract some bash or whatever old definitions and build new per language php file (keep in mind we need those definitions on runtime, not on configure time) when we can put it in ready to use php file. There is no new build system. The livedocs build system will not work without the phpdoc (~ smarty, peardoc, etc) build system behind. It will not be able to find the files, generate the entities, etc. There are really only a few small problems with the build system (if any). We have a lot more problems with the presentation and distribution system, and livedocs is aimed at solving that. If we concentrate our efforts on rewriting the build system from the ground up, then the presentation problems will be solved a lot later. Users are not interested in how the documentation is built, they are interested in using the most up to date and best presentation format available. Livedocs is the help to make that possible. PHPdoc authors are interested in how the build system works, and they are interested in using the most developer-friendly system as possible. Copy-pasting is not the best known developer-friendly method. Goba
Re: [PHP-DOC] [PATCH] rtl
more feedbacks?
goba, adding new i18n.php file that will hold the languages data is
agreed?
--/moshe.
My proposal:
in common.php have something like this:
$rtl_langs = array('he',);
if (isset($rtl_langs[$lang]) {
define('RTL', 1);
}
$chars = array('he' = 'ISO-xpto'; 'ja'='BIG-5' ,..);
define('CHARSET', isset($chars[$lang]) ? $chars[$lang] : 'default
charset');
/***/
in style_mapping:
$map = array (..);
if(RTL) {
// differences to normal $map array
$map['emphasis'] = 'format_emphasis';
.
// declaration of special functions for RTL
format_emphasis () {
..
}
}
/*/
Also change the templates to use RTL and CHARSET.
Nuno
Re: [PHP-DOC] [PATCH] rtl
no rejections.
Nuno Lopes [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
more feedbacks?
goba, adding new i18n.php file that will hold the languages data is
agreed?
--/moshe.
My proposal:
in common.php have something like this:
$rtl_langs = array('he',);
if (isset($rtl_langs[$lang]) {
define('RTL', 1);
}
$chars = array('he' = 'ISO-xpto'; 'ja'='BIG-5' ,..);
define('CHARSET', isset($chars[$lang]) ? $chars[$lang] : 'default
charset');
/***/
in style_mapping:
$map = array (..);
if(RTL) {
// differences to normal $map array
$map['emphasis'] = 'format_emphasis';
.
// declaration of special functions for RTL
format_emphasis () {
..
}
}
/*/
Also change the templates to use RTL and CHARSET.
Nuno
Re: [PHP-DOC] [PATCH] rtl
Moshe Doron wrote: Mehdi Achour [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I'm 100% with Gabor here. We should only focus on the rendering part now. The build system will remain the same for the moment. Moshe, can you please wait for an answer before commiting ? Next time, please propose the patch *before* commiting it, it will avoid us to commit, revert, re-commit and it will be more easy to keep an eyes on livedocs sources :) sorry for the wrong commit. the reason i'm not removing the files is just to let someone with filesystem access do the removal on the filesystyem level for not spam the attic. anyway what you opinion about adding i18n.php file with array that will hold languages charset and direction? Amen :)
Re: [PHP-DOC] [PATCH] rtl
Please tell me what RTL mean ? Thanks http://www.raovat.org - Original Message - From: Derick Rethans [EMAIL PROTECTED] To: Nuno Lopes [EMAIL PROTECTED] Cc: moshe doron [EMAIL PROTECTED]; PHPdoc [EMAIL PROTECTED] Sent: Monday, May 03, 2004 3:42 PM Subject: Re: [PHP-DOC] [PATCH] rtl On Sun, 2 May 2004, Nuno Lopes wrote: But I think we don't need any other file for RTL. We need just an array (sorry Derick :)) with the languages that use RTL. I never said we shouldn't do that, i said you did it in the wrong place. Derick
Re: [PHP-DOC] [PATCH] rtl
On Mon, 3 May 2004, moshe doron wrote: We need also to decide how to choose the encoding and how to choose if RTL or LTR for each language. Create an array with this info? It's dificult to extract this info from the old (actual) build system because livedocs can be used for more than one language. i'm +1 for array method. more feedbacks? can i put the languages array in new i18n.php file? s l o w d o w n a bit, people are away sometimes and need more time to read/answer to emails. Derick
Re: [PHP-DOC] [PATCH] rtl
Gabor Hojtsy [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi Moshe, In 3 months delay cause by work loading here is rtl: http://moshe.i-com-it.com/patchs/livedocs-rtl.patch.txt Here is reminder what i did: 1. Make the style_mapping.php (optionally - default english) per language version: first, already now it contains plain text that have to be changed per language. second, that methos will give me maximum ability for RTL customizing with minmum delta from livedocs, when i can define format_* functions where neeeded (e.g, to add nbsp;'s and so on.) This is not manageable. Now if we need to modify the formatting, that needs to be modified in all the language files. The language dependent strings will not be stored in the style mapping file of course, this is just a start... So that is not a valid reason to have one for every language. Could you please explore if you would be able to integrate the RTL stuff into the style mapping harmlessly - and let us discuss before you commit the changes? Thanks, Goba The issue you raise here is more files arrangement Issue then real issue. what about one file per language that contains all the strings using the on the next phases and include() on the end of the file rtl_style_mapping or ltr_style_mapping? if ok, someone with filesystem access to the cvs may commit the changes by renaming the *original* filenames for saving the history (my commit was just a way to demonstrate the change, anyway commiting change link this involve manually playing with the files). --/moshe
Re: [PHP-DOC] [PATCH] rtl
The issue you raise here is more files arrangement Issue then real issue. what about one file per language that contains all the strings using the on the next phases and include() on the end of the file rtl_style_mapping or ltr_style_mapping? if ok, someone with filesystem access to the cvs may commit the changes by renaming the *original* filenames for saving the history (my commit was just a way to demonstrate the change, anyway commiting change link this involve manually playing with the files). --/moshe I think that having a file for each language with the strings is OK. But I think we don't need any other file for RTL. We need just an array (sorry Derick :)) with the languages that use RTL. Which languages use RTL? and which charset? Nuno P.S.: can you please revert your patch?
Re: [PHP-DOC] [PATCH] rtl
Nuno Lopes [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] The issue you raise here is more files arrangement Issue then real issue. what about one file per language that contains all the strings using the on the next phases and include() on the end of the file rtl_style_mapping or ltr_style_mapping? if ok, someone with filesystem access to the cvs may commit the changes by renaming the *original* filenames for saving the history (my commit was just a way to demonstrate the change, anyway commiting change link this involve manually playing with the files). --/moshe I think that having a file for each language with the strings is OK. But I think we don't need any other file for RTL. RTL changes are not just dump dir='rtl' on some tags. there are somtimes span to div changes or inserting nbsp; to patch rtl and ltr issues. 1. i see no much sense polluting the orginal file with if()'s and needless functions (btw, if performance is your hobby you losing here due to needless functions calls). 2. since the rtl support is still experiment (on most of the applications btw), naturally i'will commit relatively much small tunings - and i prefer respecting your peace by working on separated file. synchronizing this file is not such a big deal and i can take this on myself. may you changed your mind? We need just an array (sorry Derick :)) with the languages that use RTL. Which languages use RTL? and which charset? hebrew : window-1255 arabic persian Nuno P.S.: can you please revert your patch?
Re: [PHP-DOC] [PATCH] rtl
I think that having a file for each language with the strings is OK. But I think we don't need any other file for RTL. We need just an array (sorry Derick :)) with the languages that use RTL. Which languages use RTL? and which charset? A lot of strings can be extracted from the phpdoc build system (entities used for translation). Also the phpdoc build system is aware of what language is RTL or LTR, so there is no need to duplicate this. Goba
Re: [PHP-DOC] [PATCH] rtl
Are you planing to use on the old build system forever? Shouldn't livdocs replace completely the old system sometime? also if the answers to those two questions are yes and no, Imho, the multi languages support on the old build is realy creak part (specially in the aspect of not duplication the code and files-structure) and and we sould reduce the old build system relay as much as possible. It's just looks to me stupid giving the new build system the pleasure to extract some bash or whatever old definitions and build new per language php file (keep in mind we need those definitions on runtime, not on configure time) when we can put it in ready to use php file. --/moshe. Gabor Hojtsy [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I think that having a file for each language with the strings is OK. But I think we don't need any other file for RTL. We need just an array (sorry Derick :)) with the languages that use RTL. Which languages use RTL? and which charset? A lot of strings can be extracted from the phpdoc build system (entities used for translation). Also the phpdoc build system is aware of what language is RTL or LTR, so there is no need to duplicate this. Goba
Re: [PHP-DOC] [PATCH] rtl
The old build system is used when you run build.sh in livedocs. It does a ./configure --with-lang=$lang I don't know if we will ever get ride of this build system. The use of entities is a good idea, Goba! we may add the entites for livedocs in language-snippets.ent, for example. Moshe: There won't be too many IFs. We need just one if for the array $map and other IF to declare your special functions. No real impact on performance and its much more manageable. Anyway, any more opinions? We need also to decide how to choose the encoding and how to choose if RTL or LTR for each language. Create an array with this info? It's dificult to extract this info from the old (actual) build system because livedocs can be used for more than one language. Nuno Are you planing to use on the old build system forever? Shouldn't livdocs replace completely the old system sometime? also if the answers to those two questions are yes and no, Imho, the multi languages support on the old build is realy creak part (specially in the aspect of not duplication the code and files-structure) and and we sould reduce the old build system relay as much as possible. It's just looks to me stupid giving the new build system the pleasure to extract some bash or whatever old definitions and build new per language php file (keep in mind we need those definitions on runtime, not on configure time) when we can put it in ready to use php file. --/moshe. Gabor Hojtsy [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I think that having a file for each language with the strings is OK. But I think we don't need any other file for RTL. We need just an array (sorry Derick :)) with the languages that use RTL. Which languages use RTL? and which charset? A lot of strings can be extracted from the phpdoc build system (entities used for translation). Also the phpdoc build system is aware of what language is RTL or LTR, so there is no need to duplicate this. Goba
Re: [PHP-DOC] [PATCH] rtl
Are you planing to use on the old build system forever? Shouldn't livdocs replace completely the old system sometime? Livedocs is currently not aimed at replacing the complete build system. Livedocs itself needs command line tools to build the index and configure the system. It does not know that much about the built documentation, and it does not need to know that much. Livedocs was planned to be available for not only phpdoc but for other projects as well (smarty, peardoc and php-gtk are the next target beyond phpdoc). We are not planning to use the current build system forever, we don't have plans for the infinite future. Since we are not in a position to require PHP 5 to run livedocs (it needs to run on all PHP.net mirror sites and client machines as well), we cannot eliminate the need to use libxml2 and some command line tools to glue these together. The configure and make tools in the phpdoc build system do a lot to ensure that partial results are cached, and reused as possible. If we would employ a dumb PHP based build system, these advantages would be lost. There is no PHP based build system yet running with PHP 4.x.x AFAIK. also if the answers to those two questions are yes and no, Imho, the multi languages support on the old build is realy creak part (specially in the aspect of not duplication the code and files-structure) and and we sould reduce the old build system relay as much as possible. It's just looks to me stupid giving the new build system the pleasure to extract some bash or whatever old definitions and build new per language php file (keep in mind we need those definitions on runtime, not on configure time) when we can put it in ready to use php file. There is no new build system. The livedocs build system will not work without the phpdoc (~ smarty, peardoc, etc) build system behind. It will not be able to find the files, generate the entities, etc. There are really only a few small problems with the build system (if any). We have a lot more problems with the presentation and distribution system, and livedocs is aimed at solving that. If we concentrate our efforts on rewriting the build system from the ground up, then the presentation problems will be solved a lot later. Users are not interested in how the documentation is built, they are interested in using the most up to date and best presentation format available. Livedocs is the help to make that possible. PHPdoc authors are interested in how the build system works, and they are interested in using the most developer-friendly system as possible. Copy-pasting is not the best known developer-friendly method. Goba
Re: [PHP-DOC] [PATCH] rtl
Nuno Lopes [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] The old build system is used when you run build.sh in livedocs. It does a ./configure --with-lang=$lang I don't know if we will ever get ride of this build system. The use of entities is a good idea, Goba! we may add the entites for livedocs in language-snippets.ent, for example. Moshe: There won't be too many IFs. We need just one if for the array $map and other IF to declare your special functions. No real impact on performance and its much more manageable. Anyway, any more opinions? i'm not realy care about this point. my initial intuition was to split the files but IFs also have gains. We need also to decide how to choose the encoding and how to choose if RTL or LTR for each language. Create an array with this info? It's dificult to extract this info from the old (actual) build system because livedocs can be used for more than one language. i'm +1 for array method. --/moshe.
