From seth at untethered.org Sun Nov 2 01:31:08 2008 From: seth at untethered.org (seth) Date: Sat, 1 Nov 2008 20:31:08 -0500 Subject: [search-ui] Search UI Bugtracker In-Reply-To: <39BBFD5B-21D9-4DA7-9458-C01112D701C9@jabber.org> References: <49097685.6070208@gmx.de> <39BBFD5B-21D9-4DA7-9458-C01112D701C9@jabber.org> Message-ID: <4BA47667-F4E0-43C2-9F1E-6C8DD917D8A5@untethered.org> We've stopped using panther for KT calls. Hoping this will resolve some of the issues around saves sometimes not working, or at least eliminate a possible source. seth On Oct 30, 2008, at 11:38 AM, Jeremie Miller wrote: > I am as well :) > > On Oct 30, 2008, at 9:09 AM, David Pean wrote: > >> I'm subscribed to all bugs now :) >> >> On Thu, Oct 30, 2008 at 4:55 AM, Rainer Blome >> wrote: >> David Pean wrote: >>> We set up a new bugtracker on Launchpad. If anyone has any recent / >>> unresolved issues, please add them to the site. >>> >>> https://bugs.launchpad.net/wikia-search >> >> As far as I can see, Markie is the only one subscribed to "all >> issues". >> How are bugs assigned to developers? >> Are all developers signed up? >> Will all involved get added to a Launchpad team for Wikia Search? >> >> Rainer >> >> PS: This one has been bugging since June: >> >> [https://bugs.launchpad.net/wikia-search/+bug/290996 contributions do >> not show up in results] >> _______________________________________________ >> Search-UI mailing list >> Search-UI at wikia.com >> http://lists.wikia.com/mailman/listinfo/search-ui >> >> _______________________________________________ >> Search-UI mailing list >> Search-UI at wikia.com >> http://lists.wikia.com/mailman/listinfo/search-ui > > _______________________________________________ > Search-UI mailing list > Search-UI at wikia.com > http://lists.wikia.com/mailman/listinfo/search-ui From jeremie at jabber.org Fri Nov 14 20:20:21 2008 From: jeremie at jabber.org (Jeremie Miller) Date: Fri, 14 Nov 2008 14:20:21 -0600 Subject: [search-ui] Internationalization help In-Reply-To: References: <6704a5e60811111015v55c59ec8vd133bc149c78a304@mail.gmail.com> <683754A3-5F33-49A7-95FA-AC0A3053181B@jabber.org> Message-ID: Thanks, I've cc'd the search-ui list to discuss this some more... search-ui folks, I'm way out of my fish tank on what we can/should do here, but he sent along this URL http://www.i18nguy.com/markup/right-to-left.html I'm wondering, for RTL languages, would it at least help to change some of these CSS attributes? Anyone here and experiences along these lines? Jer On Nov 13, 2008, at 6:36 AM, mmm nnn wrote: > Hello, > > Sorry for sending too many messages about the Arabic interface -as > you are probably busy-, but I wanted to say that the changes needed > to make the interface RTL is changing the places for some elements > (Is the word correct?<328.png>). > > Things like the search box (should be on the left instead of right), > and the sign reads "Sign Up/Register", and the results (should be > like Google). > > I don't know if that helps or not, just I was trying to help making > things easier. > > Sorry for any annoyance, and Thank you. > > Mohammad > > On Wed, Nov 12, 2008 at 3:36 AM, Jeremie Miller > wrote: > Hi Mohammad, what can I do to help? > > I'm really inexperienced with right-to-left formatting, but if > there's code you think you know how to fix or suggestions just let > me know, I'd love to get it working the right way, I just don't know > what that is :) > > Thanks! > > Jer > > > On Nov 11, 2008, at 12:15 PM, Dan Lewis wrote: > > No problem. I'll loop in Jeremie, our tech lead, cc:ed > > On Tue, Nov 11, 2008 at 1:07 PM, mmm nnn wrote: > Hello, > I sent you a message regarding the Arabic interface for wikia but > got no > response, Is there any problem? > > Sincerely, > Mohammad > > > > > -- > The message is intended only for the use of the individual(s) and/or > entity to which it is addressed and may contain information that is > privileged, confidential, and exempt from disclosure under applicable > law. If the reader of this message is not the intended recipient, you > are hereby notified that any dissemination, distribution, or copying > of this email is strictly prohibited. If you have received this email > in error, please notify me by reply email and delete the original > message. Thank you. > > > > Read more >> Options >> > From rainer.blome at gmx.de Sat Nov 15 00:37:23 2008 From: rainer.blome at gmx.de (Rainer Blome) Date: Sat, 15 Nov 2008 01:37:23 +0100 Subject: [search-ui] Trying to understand Right-To-Left fundamentals In-Reply-To: References: <6704a5e60811111015v55c59ec8vd133bc149c78a304@mail.gmail.com> <683754A3-5F33-49A7-95FA-AC0A3053181B@jabber.org>

Message-ID: <491E19C3.8090005@gmx.de> Hi Mohammad, RTL is an interesting issue. To learn, I have read the page that that link points to, and I searched a little (for example for "javascript rtl string"), but without good results. So I experimented a little. If anyone knows of any documentation about this topic, please point us there. Here are my thoughts and impressions, please correct me ruthlessly: Layout o The layout of an right-to-left (RTL) web page is usually a mirrored version of an equivalent LTR page. o A web page in general is a sequence of nested elements. The nesting terminates in characters. (Please correct my terminology here.) Plain text (character sequences that do not represent markup) is treated specially, see below. For now, I am going to ignore the issue of non-ASCII tag or attribute names. o An element can contain a sequence of other elements. By default, the contained elements are arranged LTR. To mirror a layout, the containing element can specify the DIR="RTL" attribute. Testing this, I added this setting to search.html's tag. The effect is that some of the layout is mirrored - but not all of it. - Some areas are now right-justified, - some sequences are mirrored, for example "query number, search button, input field", - some arabic text that logically *follows* english text is correctly placed to the *left* of the english text. Other areas do not change. Apparently the attribute is not inherited by all contained elements. My guess is that generating and loading a dedicated style sheet might fix this, but this is out of my capabilities. o Up to now, when the language was changed, the language selection "button" did not move, it was still in the lower right corner. This made it relatively easy to find it even when one could not read the current language and wanted to switch to another language. If the layout of the page is switched, the language button could become hard to recognize. To alleviate this, a fixed graphical symbol might be used that makes it easy to recognize the button independently of the current language, for example a babelfish :-). o Beyond RTL scripts, there are also top-to-bottom (TTB) scripts. For TTB, should the layout be turned on the side? For example, where should the menu be kept? On one of the the sides, using "pop-rights"? Regarding vanilla text, alias character sequences: o In Javascript, how are RTL strings represented? With LTR strings, the character index increases from left to right. For example "OK"[0] is "O", and "OK"[1] is "K". Note: To be able to correctly read the following paragraphs, you need a unicode-capable mail reader. Now to RTL strings. Suppose that there is an arabic word pronounced "ba" (a translation service tells be that there isn't, please don't let this be a dirty word ;-). In english, this hypothetical word can be spelled as pronounced, first "b" on the left, then "a" on the right. In arabic, it might be spelled first "?" ("b"), then "?" ("a"). Taken together, because the "word" is written from right to left, this becomes "??" (left side "?" ("a"), right side "?" ("b")). Now I want to represent this arabic word as a Javascript string. Surprisingly, var word="??"; alert(word[0]); yields "?" ("b") as the "first character", without any special intervention. Conversely, var a="?"; var b="?"; var arr= []; arr[0]= b; arr[1]= a; alert(arr.join('')); yields "??" ("a" comes second, on the left side). Apparently JavaScript internally represents strings in "conceptual" order and only imposes the expected output order during printing. In other words, sequences of characters should be automatically printed in the correct order. Why am I doing the above in such a complicated JavaScript fashion? Answer: Because editors have their hand in this business, too. When I type and paste characters of a RTL language, the editor sometimes joins sections of consecutive RTL characters and reverses the order of the characters, on the fly (both the Safari console and my mail client do this). Surprisingly, it does so across instances of '"+"' (double quote, plus, double quote). For me this makes it hard if not impossible to know what the editor has "understood". Try it in your editor. Also try to mark the "alert" argument expression with your pointing device: alert("?" + "?"); (I do not claim to know the order of characters in the above expression). How are they printed in the browser? What happens when I have a variable "text" whose value is a string of RTL characters and "print" the value, for example using "document.write(text)", or "alert(text)"? Another experiment: function individualize(text) { var separator= " xyz "; // Keeps some LTR between RTL chars var char_array= text.split(''); alert("individual chars: "+char_array.join(separator)); } function rtl_test(text) { alert("plain: "+text+" - Next will be just the text, without english decoration - see if it looks the same"); alert(text); individualize(text); individualize("before"+text+"after"); } var wiki="??????"; // Supposed to mean "Wiki" rtl_test(wiki); Rainer From david.pean at gmail.com Mon Nov 17 17:03:41 2008 From: david.pean at gmail.com (David Pean) Date: Mon, 17 Nov 2008 12:03:41 -0500 Subject: [search-ui] Contributions Debugging Message-ID: We've been trying to track some reports of contributions not being saved. There have been several bug fixes over the past week that should have eliminated some cases, and there is now more error reporting through custom alerts should a known error occur in KT (expired token etc). If anyone keeps experiencing occurrences where their saves silently fail, there is a way to check out what is going on behind the scenes if you use something like the FireBug extension for FireFox. https://addons.mozilla.org/en-US/firefox/addon/1843 Technical stuff, for those interested :) When a user makes a save, the code is injecting a javascript URL that sends all the necessary information to the KT server For example: http://kt.search.isc.org/kt/2/new.js?t=stars&k=college%20basketball&v=1226940769000:8e4c65b40391634ad3fbd6a5292277ed&j=JSONGOES HERE&r=0.13523420044139212 If you have FireBug running with a live view of the HTML, you should see Javascript URLs like this appear in the head when you make saves. When you expand the contents of the url, you can see the response the KT server gave. If all goes well, it should give back "processKTN('Good')" (which is a function in our code that gets run). Anytime you can get a repeatable case of things not saving, check the response and send in the error and URL that caused it (preferably in the BugTracker) so we can track it down easier. Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.wikia.com/pipermail/search-ui/attachments/20081117/ae5bf40b/attachment.html From jeremie at jabber.org Mon Nov 17 18:53:50 2008 From: jeremie at jabber.org (Jeremie Miller) Date: Mon, 17 Nov 2008 12:53:50 -0600 Subject: [search-ui] Trying to understand Right-To-Left fundamentals In-Reply-To: <491E19C3.8090005@gmx.de> References: <6704a5e60811111015v55c59ec8vd133bc149c78a304@mail.gmail.com> <683754A3-5F33-49A7-95FA-AC0A3053181B@jabber.org>

<491E19C3.8090005@gmx.de> Message-ID: This is an incredibly in-depth and tremendously helpful write-up Rainer, I hope it's just as or even more useful to others or anyone looking for this kind of info in the future. I'm not sure how to "get practical" yet and make the change-language event start flipping some of these bits, do you have suggestions on where best to start that might be the most helpful starting points? Thanks again, very informative :) Jer On Nov 14, 2008, at 6:37 PM, Rainer Blome wrote: > Hi Mohammad, > > RTL is an interesting issue. To learn, I have read the page that that > link points to, and I searched a little (for example for "javascript > rtl > string"), but without good results. So I experimented a little. > If anyone knows of any documentation about this topic, please point us > there. Here are my thoughts and impressions, please correct me > ruthlessly: > > Layout > > o The layout of an right-to-left (RTL) web page is usually a mirrored > version of an equivalent LTR page. > > o A web page in general is a sequence of nested elements. The nesting > terminates in characters. (Please correct my terminology here.) Plain > text (character sequences that do not represent markup) is treated > specially, see below. For now, I am going to ignore the issue of > non-ASCII tag or attribute names. > > o An element can contain a sequence of other elements. By default, > the > contained elements are arranged LTR. To mirror a layout, the > containing > element can specify the DIR="RTL" attribute. Testing this, I added > this > setting to search.html's tag. The effect is that some of the > layout is mirrored - but not all of it. > - Some areas are now right-justified, > - some sequences are mirrored, for example > "query number, search button, input field", > - some arabic text that logically *follows* english text is correctly > placed to the *left* of the english text. > Other areas do not change. Apparently the attribute is not inherited > by > all contained elements. My guess is that generating and loading a > dedicated style sheet might fix this, but this is out of my > capabilities. > > o Up to now, when the language was changed, the language selection > "button" did not move, it was still in the lower right corner. > This made it relatively easy to find it even when one could not read > the > current language and wanted to switch to another language. If the > layout of the page is switched, the language button could become > hard to > recognize. To alleviate this, a fixed graphical symbol might be used > that makes it easy to recognize the button independently of the > current > language, for example a babelfish :-). > > o Beyond RTL scripts, there are also top-to-bottom (TTB) scripts. For > TTB, should the layout be turned on the side? For example, where > should > the menu be kept? On one of the the sides, using "pop-rights"? > > > Regarding vanilla text, alias character sequences: > > o In Javascript, how are RTL strings represented? > > With LTR strings, the character index increases from left to right. > For > example "OK"[0] is "O", and "OK"[1] is "K". > > Note: To be able to correctly read the following paragraphs, you > need a > unicode-capable mail reader. > > Now to RTL strings. Suppose that there is an arabic word pronounced > "ba" (a translation service tells be that there isn't, please don't > let > this be a dirty word ;-). In english, this hypothetical word can be > spelled as pronounced, first "b" on the left, then "a" on the right. > In > arabic, it might be spelled first "?" ("b"), then "?" ("a"). Taken > together, because the "word" is written from right to left, this > becomes > "??" (left side "?" ("a"), right side "?" ("b")). > Now I want to represent this arabic word as a Javascript string. > Surprisingly, > var word="??"; alert(word[0]); > yields "?" ("b") as the "first character", without any special > intervention. > > Conversely, > var a="?"; var b="?"; var arr= []; arr[0]= b; arr[1]= a; > alert(arr.join('')); > yields "??" ("a" comes second, on the left side). > > Apparently JavaScript internally represents strings in "conceptual" > order and only imposes the expected output order during printing. > In other words, sequences of characters should be automatically > printed > in the correct order. > > Why am I doing the above in such a complicated JavaScript fashion? > Answer: Because editors have their hand in this business, too. When I > type and paste characters of a RTL language, the editor sometimes > joins > sections of consecutive RTL characters and reverses the order of the > characters, on the fly (both the Safari console and my mail client do > this). Surprisingly, it does so across instances of '"+"' (double > quote, plus, double quote). For me this makes it hard if not > impossible > to know what the editor has "understood". Try it in your editor. > Also > try to mark the "alert" argument expression with your pointing device: > > alert("?" + "?"); > > (I do not claim to know the order of characters in the above > expression). > > How are they printed in the browser? What happens when I have a > variable "text" whose value is a string of RTL characters and "print" > the value, for example using "document.write(text)", or "alert(text)"? > > Another experiment: > > function individualize(text) { > var separator= " xyz "; // Keeps some LTR between RTL chars > var char_array= text.split(''); > alert("individual chars: "+char_array.join(separator)); > } > function rtl_test(text) { > alert("plain: "+text+" - Next will be just the text, without english > decoration - see if it looks the same"); > alert(text); > individualize(text); > individualize("before"+text+"after"); > } > var wiki="??????"; // Supposed to mean "Wiki" > rtl_test(wiki); > > Rainer > _______________________________________________ > Search-UI mailing list > Search-UI at wikia.com > http://lists.wikia.com/mailman/listinfo/search-ui From rainer.blome at gmx.de Mon Nov 17 22:56:59 2008 From: rainer.blome at gmx.de (Rainer Blome) Date: Mon, 17 Nov 2008 23:56:59 +0100 Subject: [search-ui] Trying to understand Right-To-Left fundamentals In-Reply-To: References: <6704a5e60811111015v55c59ec8vd133bc149c78a304@mail.gmail.com> <683754A3-5F33-49A7-95FA-AC0A3053181B@jabber.org>

<491E19C3.8090005@gmx.de> Message-ID: <4921F6BB.50809@gmx.de> Jeremie Miller wrote: > I'm not sure how to "get practical" yet and make the change-language > event start flipping some of these bits, My view is that the on-the-fly changing is a goodie, a "nice to have". (But I love it). I don't even know how to statically get the desired layout. > do you have suggestions on > where best to start that might be the most helpful starting points? As I said: >> ... My guess is that generating and loading a >> dedicated style sheet might fix this, but this is out of my >> capabilities. If I had to do this on my own, this would be my course: o Find out how to statically achieve the desired RTL layout. This is work for web design cracks. o Where does DIR='RTL' have to be individually applied (which divs, iframes or whatever containers need their own use of DIR)? o Which uses of absolute sides (right or left) need to be changed to "before" and "after"? Which otherwise hard-coded positioning needs to be changed? o Find out whether the RTL layout works well enough for the desired browsers. o Find out whether the DIR attribute value can be dynamically changed, for *all required elements (it can be dynamically changed for div elements, for example). If yes, change them when an RTL language is selected. The mapping from language code to direction can be hard-coded. If the use of style sheets is desired: o Confirm the assumption that the DIR attribute can be used from a style sheet. o Cast the settings into an additional style sheet. Is it possible to apply multiple style sheets to the same elements? I do not know. If yes, load the style sheet when an RTL language is selected. o Find out whether settings made by a style sheet can be overruled by a subsequent load of a different style sheet. > Thanks again, very informative :) You are welcome. Experiments that yield interesting results are the best. Here's another one, add this to the "add-site" form in search.html: Watch out for the buttons swapping their places. Rainer From rainer.blome at gmx.de Sat Nov 29 01:44:33 2008 From: rainer.blome at gmx.de (Rainer Blome) Date: Sat, 29 Nov 2008 02:44:33 +0100 Subject: [search-ui] Right-To-Left layout Message-ID: <49309E81.3020707@gmx.de> Disclaimer: Much of this should really go in the wiki, on a dedicated page. However, I want to get this out the door now, since I need to reboot. :-/ Having recently installed Firebug, I've used it to play with search.html, style.css and structure.css (and Firebug is a marvelous tool). This is what I've learned: In summary, the most promising path achieve Right-to-Left layout seems to me to try to remove all absolute layout, replacing it by relative layout as needed. In particular, using so-called inline containers (or, if need be, tables) to layout elements that should appear next to each other (as opposed to above each other) can automate mirroring the layout when dir:rtl is added. In detail: In some ways, the browser should automatically mirror the layout when the direction is changed from "ltr" to "rtl", or the other way around. For example, the visual order of table columns and of the so-called inline ("next-to-each-other") elements, for example in a span or a form, and the default text justification ("text-align") are automatically mirrored. However, this only works only when no absolute layout has been explicitly specified. Examples of absolute layout are: text-align:left float:left position:absolute border-left:... Currently, these are used a lot. The direction attribute is inherited by all contained elements, unless the direction attribute itself or any of the other attributes that it affects are changed from their default values. In particular, it affects the default values of text-align and block progression (float, whether the next element comes to the right or to the left). The layout of the entire document can thus automatically be mirrored by changing the direction of the "html" tag or the "document" object. "dir:rtl" (or, I think, "direction", in a style sheet) is added to indicate Right-To-Left. Regarding "text-align:left": Explicit uses of "text-align" are not automatically "mirrored" when "dir:rtl" is used and should therefore be avoided. Instead, leave the default text alignment as it is ("left"). This way, when the direction of entire document is changed from "ltr" to "rtl", the default alignment is automatically changed along from "left" to "right". In order to be able to avoid using "text-align:left", a global (used for all pages) top-level "text-align:center" must not be used. Centering should instead be specified only where needed. Regarding "border-left:...": Instead of using an absolutely positioned border on an existing element in order to create a divider, create a dedicated divider element, "inline". The separate element should simply flow in the default writing direction, changing its place as appropriate. Or use a table with an internal border. I wish there was a border-after and border-before instead. Regarding "float:left": Basically, using inline elements (spans instead of divs) should take care of this. Not sure how to handle these otherwise. I wish there was a float:inline . Regarding "position:absolute": These should be and can be at least largely avoided by using span instead of div, except where necessary. More I do not know yet. Another case is display:block, as it seems that it can force line breaks in unwanted places. "display:inline" should be used instead. For the last element in a block, this is not apparent with LTR layout, since the block is terminated anyway. With RTL layout however, the last element becomes the leftmost one. For some reason, the block can be terminated and the next element rendered on the next line, if I remember correctly. Rainer References Here are links to some good resources that I've found: "What you need to know about the bidi algorithm and inline markup" http://www.w3.org/International/articles/inline-bidi-markup/ "W3C Internationalization (I18n) Activity" http://www.w3.org/International/ "Tutorial: Creating (X)HTML Pages in Arabic & Hebrew" http://www.w3.org/International/tutorials/bidi-xhtml/ "Internationalization Best Practices: Handling Right-to-left Scripts in XHTML and HTML Content" http://www.w3.org/International/geo/html-tech/tech-bidi.html HTML 4 standard, in section 8.2 "Specifying the direction of text and tables: the dir attribute": http://www.w3.org/TR/1999/REC-html401-19991224/struct/dirlang.html#h-8.2 HTML 4 standard, "Table directionality" http://www.w3.org/TR/1999/REC-html401-19991224/struct/tables.html#table-directionality On using the dir attribute: http://www.microsoft.com/globaldev/handson/dev/mideast.mspx Below are some updates regarding my previous mail. Rainer Blome wrote: > please correct me ruthlessly: Will do :-) > Layout > ... > For now, I am going to ignore the issue of > non-ASCII tag or attribute names. Non-ASCII tag names are not allowed, as far as I know. > By default, the contained elements are arranged LTR. It depends, on both the containing and the contained elements. Only if both use "inline" sequencing (progression?) are the elements arranged next to each other (space permitting). > o Beyond RTL scripts, there are also top-to-bottom (TTB) scripts. For > TTB, should the layout be turned on the side? ... The block-progression attribute needs to be used to correctly layout TTB text. This has not been standardized yet, so I'll ignore this for now. > Regarding vanilla text, alias character sequences: > > o In Javascript, how are RTL strings represented? In Javascript, at run-time, all strings are represented in "logical order" alias "spoken order" alias "conceptual order". The "visual order" is independent of this and imposed by the browser. See "What you need to know about the bidi algorithm and inline markup" http://www.w3.org/International/articles/inline-bidi-markup/ > Why am I doing the above in such a complicated JavaScript fashion? > Answer: Because editors have their hand in this business, too. And my editor sometimes renders RTL language strings in the wrong way, using LTR visual order. Haven't figured out why yet.