Re: TransitionMLS scenario

Marty Vance wrote:
> marcinmilanxaraya.com wrote:
>> Marty Vance wrote:
>>
...
> 
> I present this as a way to translate strings that are
not handled by 
> xaraya, specifically extrenal js files that contain
hard coded English 
> text.  For example, TinyMCE seens to have some sort of
internal 
> tanslation mechanism, but itdoesn't sem to be
universally used.  There 
> are several lines such as
> 
>     alert("Error: Could not find the target
element.");
> 
> In that module's javascript files.
> 
> I'm not proposing a different scheme, just a method to
deliver stings 
> that otherwise never get the opportunity to be run
through xarML() 
> because they only exist inside teh browser.

Ideally the new MLS should handle "everything",
but we still have far to 
go in that discussion.

> 
> HTML <pre> is not about what language it's child
nodes are in, it's 
> about how they are formatted when rendered in the
browser.  The tag is 
> the structural equivalent of declaring
"white-space: pre;" in CSS.
> 
...>
> The newline between the words is not ignored inside the
<pre>. Replacing 
> "Hello,nWorld!" with
"HallonWelt!" makes no difference.

<pre> is just one example of tags that need special
treatment of course. 
I understand that it preserves whitespace. The point is that
<pre> is 
used - in general I would say - when you want to the text
within it to 
remain unchanged. Witness the fact that in Xaraya_Classic
<pre> displays 
output in courier font. Typical use case: I want to display
a code 
snippet. Obviously such a snippet should not be translated
or even 
appear to the translations module.
> 
> Bringing CDATA into the issue only confuses it more. 
We don't have to 
> sprinkle CDATA everywhere, we just need a way to change
the default 
> behavior (translate) off on a tag by tag basis.

That would be the first option I suggested.
> 
> Perhaps the real issue here is when is a CDATA element
meant for BL, and 
> when is it meant to pass through BL unmolested and sent
to the browser? 
>  This leads me to believe that a more illustrative
example then <pre> 
> would be <script>, where code is commonly wrapped
in CDATA.
> 
A similar issue, but perhaps a bit more complicated as we
sometimes want 
parts of the js to be translated. For instance that js
snippet in base 
module that checks for required fields.
>>>> 
> I think #...# inside the child of xar:set is
superfluous.
> 
I guess it is in many cases. The question is, should it even
be allowed 
in that case.
>>>
>>> 
> For the record, I think ##...# as a way to turn off
variable handling is 
>  not ideal.

Right now the scenario takes ## to mean "echo the hash
character". The 
above would blow up because of the last #. To disable
variable handling 
in the scenario would be: ##$foo##
_______________________________________________
Xaraya_devel mailing list
Xaraya_develxaraya.com
http:
//xaraya.com/mailman/listinfo/xaraya_devel

marcinmilanxaraya.com wrote:


> 
>> The newline between the words is not ignored inside
the <pre>. 
>> Replacing "Hello,nWorld!" with
"HallonWelt!" makes no difference.
> 
> 
> <pre> is just one example of tags that need
special treatment of course. 
> I understand that it preserves whitespace. The point is
that <pre> is 
> used - in general I would say - when you want to the
text within it to 
> remain unchanged. Witness the fact that in
Xaraya_Classic <pre> displays 
> output in courier font. Typical use case: I want to
display a code 
> snippet. Obviously such a snippet should not be
translated or even 
> appear to the translations module.

When you want the text unchanged, yes, but not necessarily
untranslated 
during backend processing.

Browser defaults use a fixed width font for <pre>.

If you want to display a code snippet, <code> or
<samp> should be used. 
  These tags use the same formatting as <pre>, but
have the added 
semantic meaning of "this element is computer
code".  Likewise, <kbd> is 
for keyboard text (ie, user input), and <var>
indicates a computer 
variable; these two are intended for tutorials or
documentation to 
replicate display conventions in textbooks, and they have
semantic 
meaning as such.

<pre> is a formatting tag for plain old regular text,
just like <strong> 
and <em>.

The only HTML tags I think are candidates for complete
preservation are 
  <style>, <script>, <code>, and
<samp>.

> 
>>
>> Bringing CDATA into the issue only confuses it
more.  We don't have to 
>> sprinkle CDATA everywhere, we just need a way to
change the default 
>> behavior (translate) off on a tag by tag basis.
> 
> 
> That would be the first option I suggested.
> 
>>
>> Perhaps the real issue here is when is a CDATA
element meant for BL, 
>> and when is it meant to pass through BL unmolested
and sent to the 
>> browser?  This leads me to believe that a more
illustrative example 
>> then <pre> would be <script>, where
code is commonly wrapped in CDATA.
>>
> A similar issue, but perhaps a bit more complicated as
we sometimes want 
> parts of the js to be translated. For instance that js
snippet in base 
> module that checks for required fields.
> 
>>>>>
>> I think #...# inside the child of xar:set is
superfluous.
>>
> I guess it is in many cases. The question is, should it
even be allowed 
> in that case.

I would say don't allow it.

> 
>>>>
>>>>
>> For the record, I think ##...# as a way to turn off
variable handling 
>> is  not ideal.
> 
> 
> Right now the scenario takes ## to mean "echo the
hash character". The 
> above would blow up because of the last #. To disable
variable handling 
> in the scenario would be: ##$foo##

Say I have an integer $foo, with the value of 15

So to display #15 in the final output, where the regex
/#dd/ applies, 
I would write ###$foo#, or would this bomb out?
_______________________________________________
Xaraya_devel mailing list
Xaraya_develxaraya.com
http:
//xaraya.com/mailman/listinfo/xaraya_devel