Hi folks :) While I'm in the process of translating the *.tmpl files to danish I've come up with a few things I'm unsure about. The HTML in these files is giving me a bit of a hard time, frankly it's a bit tricky for my wetware to snoop around the stuff looking for strings to translate. As an aid in this matter I've made a little perl wrapper for w3.org's tidy program. This is a great help, however there are a few issues with this approach. The main thing is that it croaks on the HTML::Tidy tags, even when configuring it to accept these tags. The solution to this would be to re-write these tags as <!-- TMPL_VAR NAME='blargh' --> rather than <TMPL_VAR NAME="BLARGH"> ...this will also produce well-formed HTML which (to me at least) seems like a good idea. Another issue is when using non-ascii characters I'd prefer to use entities like "è" rather then "è" but am not sure what the general consensus on this is. Also, the tidy program seems to do a nice job of converting style-type tags into style properties/CSS - is this desireable? /bobby -- -- -- -- -- -- -- Bobby Billingsley, General Specialist -- -- -- -- -- -- -- ___ .--.- \ | | _ `-,_`--'__/ x./_ | Remember to love while you dare | ASCII ribbon campaign ( ) //-_`--/ //\ \ | remember to live while you do | - against HTML email X \__/ `---' \__/ | -- Piet Hein | & vcards / \ Lat: 55° 40' 52" N Lon: 12° 32' 56" E Anyone without a sense of humor is at the mercy of the rest of us :->
In article <20030121093649.GS19500@beastie.bofh.dk>, Bobby Billingsley <bobby@billingsley.dk> wrote: [...]
Also, the tidy program seems to do a nice job of converting style-type tags into style properties/CSS - is this desireable?
My personal opinion is that this is only partly desirable. Part of an open-source OPAC's strengths is that it can be run on a text browser. If we drop all "style-type" tags, we lose B, U, INS, DEL, HR, etc. (tags that can degrade gracefully on a text browser); CSS styles can't be trusted to do all the tasks we assume they can do. If Koha does not use B, U, INS, DEL, or HR, I guess converting the style-type tags to CSS is then indeed desirable. (Personally I think the W3C folks are somewhat misguided in their effort to rid HTML of "style" tags and/or moving to XML. They should be instead focusing on making HTML compatible of actual (human) languages. A lot of the so-called "style" tags have limited semantic functions in certain contexts but can only be safely mapped to SPAN which is completely devoid of semantics.) -- Ambrose LI Cheuk-Wing <a.c.li@ieee.org>
On Tue, Jan 21, 2003 at 03:37:27PM +0000, Ambrose Li said:
In article <20030121093649.GS19500@beastie.bofh.dk>, Bobby Billingsley <bobby@billingsley.dk> wrote: [...]
Also, the tidy program seems to do a nice job of converting style-type tags into style properties/CSS - is this desireable?
My personal opinion is that this is only partly desirable. Part of an open-source OPAC's strengths is that it can be run on a text browser. If we drop all "style-type" tags, we lose B, U, INS, DEL, HR, etc. (tags that can degrade gracefully on a text browser); CSS styles can't be trusted to do all the tasks we assume they can do.
If Koha does not use B, U, INS, DEL, or HR, I guess converting the style-type tags to CSS is then indeed desirable.
Hi Guys I think what we can do is both :-) Thats where the themes come in. IE each set of templates lives in theme/language So we could have a textonly/en/ or textonly/dk for the text based browsers. And fancy styles etc for others? Whatcha reckon? Chris -- Chris Cormack Programmer 025 500 789 Katipo Communications Ltd chris@katipo.co.nz www.katipo.co.nz
Hi
The main thing is that it croaks on the HTML::Tidy tags, even when configuring it to accept these tags. The solution to this would be to re-write these tags as
Is that HTML::Template tags?
<!-- TMPL_VAR NAME='blargh' -->
rather than
<TMPL_VAR NAME="BLARGH">
...this will also produce well-formed HTML which (to me at least) seems like a good idea.
I've no idea if you can do that - I'd assume that it wouldn't work - that html::template wouldn't parse it properly? But perhaps someone else can help with that.
Another issue is when using non-ascii characters I'd prefer to use entities like "è" rather then "è" but am not sure what the general consensus on this is.
Personally I think it's a good idea - but the people translating are perhaps in a better position to know?
Also, the tidy program seems to do a nice job of converting style-type tags into style properties/CSS - is this desireable?
How "style type"? IF you mean font tags beign converted to <h1> etc tags then great I suspect we're not ready for positioning Div tags - or we will need to start having different template sets for different browsers cheers R _____________________________________________________________ Rachel Hamilton-Williams Katipo Communications WEBMISTRESS ph 021 389 128 or +64 04 934 1285 mailto:rachel@katipo.co.nz PO Box 12487, Wellington http://www.katipo.co.nz New Zealand Koha Open Source Library System http://www.koha.org
Hej Team ... Wednesday d. 22. January 2003 skrev Rachel Hamilton-Williams:
Hi
The main thing is that it croaks on the HTML::Tidy tags, even when configuring it to accept these tags. The solution to this would be to re-write these tags as
Is that HTML::Template tags?
Ahh - yup - my bad ;)
<!-- TMPL_VAR NAME='blargh' -->
rather than
<TMPL_VAR NAME="BLARGH">
...this will also produce well-formed HTML which (to me at least) seems like a good idea.
I've no idea if you can do that - I'd assume that it wouldn't work - that html::template wouldn't parse it properly? But perhaps someone else can help with that.
According to the docs on HTML::Template it should be fine - need to double-check that though. I'll do that on my own installation.
Another issue is when using non-ascii characters I'd prefer to use entities like "è" rather then "è" but am not sure what the general consensus on this is.
Personally I think it's a good idea - but the people translating are perhaps in a better position to know?
I'll go along with the symbolic rather than the numeric entities for now then and see if there's any outcry ;)
Also, the tidy program seems to do a nice job of converting style-type tags into style properties/CSS - is this desireable?
How "style type"?
IF you mean font tags beign converted to <h1> etc tags then great
I suspect we're not ready for positioning Div tags - or we will need to start having different template sets for different browsers
Well, there seems to be some disagreement on this - I concur with Ambrose's argument that not all browsers can handle CSS stuff and with discussions on #koha that graceful degradation is a nice thing, but as Chris suggests in his mail (below), using the templates combined w. user preferences in the DB could probably achieve "the best of both worlds". However I can also see that this might prove to be more intensive in upkeep (more stuff to maintain/ translate/develop). As it stands now I feel that leaving off CSS stuff for the time being is probably the way forward. On Wed, 22 Jan 2003, Chris Cormack wrote:
Also, the tidy program seems to do a nice job of converting style-type tags into style properties/CSS - is this desireable?
My personal opinion is that this is only partly desirable. Part of an open-source OPAC's strengths is that it can be run on a text browser. If we drop all "style-type" tags, we lose B, U, INS, DEL, HR, etc. (tags that can degrade gracefully on a text browser); CSS styles can't be trusted to do all the tasks we assume they can do.
If Koha does not use B, U, INS, DEL, or HR, I guess converting the style-type tags to CSS is then indeed desirable.
Hi Guys
I think what we can do is both :-) Thats where the themes come in. IE each set of templates lives in theme/language
So we could have a textonly/en/ or textonly/dk for the text based browsers. And fancy styles etc for others?
/bobby -- -- -- -- -- -- -- Bobby Billingsley, General Specialist -- -- -- -- -- -- -- ___ .--.- \ | | _ `-,_`--'__/ x./_ | Remember to love while you dare | ASCII ribbon campaign ( ) //-_`--/ //\ \ | remember to live while you do | - against HTML email X \__/ `---' \__/ | -- Piet Hein | & vcards / \ Lat: 55° 40' 52" N Lon: 12° 32' 56" E Anyone without a sense of humor is at the mercy of the rest of us :->
Hi, In article <20030122014823.GA20359@beastie.bofh.dk>, Bobby Billingsley <koha-devel@lists.sourceforge.net> wrote:
Wednesday d. 22. January 2003 skrev Rachel Hamilton-Williams:
Personally I think it's a good idea - but the people translating are perhaps in a better position to know?
I'll go along with the symbolic rather than the numeric entities for now then and see if there's any outcry ;)
I think we all want symbolic :-) (or like Benedict or myself [when I type Chinese] just type it in whatever charset the page is supposed to be in) perhaps until we hit a language where there are no symbolic entity names. Perhaps Maori might need to use numeric? Some (all?) Maori pages seem to use numeric.
How "style type"?
IF you mean font tags beign converted to <h1> etc tags then great
I suspect we're not ready for positioning Div tags - or we will need to start having different template sets for different browsers
Well, there seems to be some disagreement on this - I concur with Ambrose's argument that not all browsers can handle CSS stuff and with discussions on #koha that graceful degradation is a nice thing, but as Chris suggests in his mail (below), using the templates combined w. user preferences in the DB could probably achieve "the best of both worlds". However I can also see that this might prove to be more intensive in upkeep (more stuff to maintain/ translate/develop). As it stands now I feel that leaving off CSS stuff for the time being is probably the way forward.
Since I haven't used HTML tidy myself, I don't know how far it will go. (I am definitely against HTML 4.0x "Strict"; if we go that far we might as well go further & use ISO 15445 :-) My only concern is that if it converts B and U tags into SPAN (or both B and U into EM), under a text browser the emphasized elements will lose their emphasis (or difference in emphasis), and we end up having something worse than before. In Koha there are some screens that rely on certain things being, e.g., bold (such as mandatory fields in the MARC editor). I.e., if HTML tidy does not actually go too far (i.e., it preserves B, U, H1, etc.), the resulting HTML+CSS pages will automatically degrade gracefully, and we won't need to split the templates into "graphical" and "text" versions unless we really want to. Or we could check all the Koha screens with a text browser and see if there are different kinds of emphasized elements. We can then run HTML tidy on one such screen and see if it has any adverse impact. -- Ambrose LI Cheuk-Wing <a.c.li@ieee.org>
-----Original Message----- From: koha-devel-admin@lists.sourceforge.net [mailto:koha-devel- admin@lists.sourceforge.net] On Behalf Of acli@ada.dhs.org via news-to- mail gateway To: koha-devel@lists.sourceforge.net Subject: [Koha-devel] Re: HTML files Summary: Expires:
I.e., if HTML tidy does not actually go too far (i.e., it preserves B, U, H1, etc.), the resulting HTML+CSS pages will automatically degrade gracefully, and we won't need to split the templates into "graphical" and "text" versions unless we really want to.
Of course, really we should be using <em> and <strong>... I've done a couple of sites in only CSS type thing, and it's easy enough to do, and isn't hard to degrade nicely. In any case, text browsers won't do <i>, which is generally more valuable (than, say U). -- My 3.7c. (I'll stay outside the box, thank you.) Patrick.
[Sorry, I'm getting off-topic for the list] In article <000001c2c1e0$13749e00$5800a8c0@pftqg.com>, Patrick Quinn-Graham <lists@pftqg.com> wrote:
Of course, really we should be using <em> and <strong>...
I've done a couple of sites in only CSS type thing, and it's easy enough to do, and isn't hard to degrade nicely. In any case, text browsers won't do <i>, which is generally more valuable (than, say U).
Yes, text browsers generally won't do I, which is a pity; I think, of all terminal emulators that I have encountered, only aixterm can do italics. I am for CSS, but I do disagree strongly about W3C's notion of "style" tags having no semantic relevance, which is of course false since semantic relevance depends on how you use it (partly depending on what the text on the web page says). And I have a strong feeling that they are deprecating useful things and at the same time creating new useless things because they don't understand how HTML is being used. (And, judging from their lack of interest in fixing the block-level-element mess, they don't even understand the languages--English even--that web pages are written in, so much for descriptive markup.) For example, they say U is just "style", but in reality they don't know that in Chinese U is a full-fledged punctuation mark (you might say "deprecated", but it is still taught in schools and people still use it) and therefore always semantically relevant in at least one language, yet there is no way to achive U, other than using U, under a normal text-browser environment. Another example: the new CSS "word-break" property, obviously designed for CJK, is, I must point out, completely useless because it requires the text to be in a "block" display context, when the only use for such a property is when the text is in an "inline" display context. Just my own $0,2's worth, -- Ambrose LI Cheuk-Wing <a.c.li@ieee.org> -- Ambrose LI Cheuk-Wing <a.c.li@ieee.org>
participants (7)
-
acli＠ada.dhs.org -
acli＠ada.dhs.org via news-to-mail gateway -
Bobby Billingsley -
Bobby Billingsley -
Chris Cormack -
Patrick Quinn-Graham -
Rachel Hamilton-Williams