Re: [gwt-contrib] An RTL Showcase

[Ian Petersen]

Nice work. I just wish I could read Arabic so I could fully enjoy it.
It looks _really_ nice in my browser. One potential bug: you seem to
have missed a translation for "redo" in the Arabic Edit menu.

Ian

--
Tired of pop-ups, security holes, and spyware?
Try Firefox: http://www.getfirefox.com

[Ray Cromwell]

  Wow, this is the first time I've seen the new Showcase. Much improved. One caveat, the menu example show scrollbars on my browser (FF2.0 mac), and I would suggest to speed up the Tree and Dialog box animated transitions.

-Ray

[Adil Allawi]

The translation is Google's - probably 'redo' was not in the translator's list of known words. But I noticed an interesting issue. Some of the Arabic labels have the colon ":" on the wrong side of the sentence. I thought that was a bug in the browser until I saw the localised files. It seems the translator put the colon on the wrong side.

Adil

[Jean-Philippe Côté]

Nice work !

What is the GWT version you use to compile this (trunk or 1.4.6*) ?

On Tue, Mar 18, 2008 at 6:11 PM, Adil Allawi <adil....@gmail.com> wrote:

The translation is Google's - probably 'redo' was not in the translator's list of known words. But I noticed an interesting issue. Some of the Arabic labels have the colon ":" on the wrong side of the sentence. I thought that was a bug in the browser until I saw the localised files. It seems the translator put the colon on the wrong side.

Adil

At 5:58 -0400 18/3/08, Ian Petersen wrote:

--
Jean-Philippe Côte

[Miguel Ping]

I'm guessing trunk :) But it is indeed very nice-looking. Guess I'll
have to update my gwt build then, just can't wait.
By the way, I'm guessing the RTL approach by gwt only needs to know if
the translation is LTR or RTL and gwt does the rest, right?

On Mar 19, 1:30 pm, "Jean-Philippe Côté"

[Adil Allawi]

Its trunk++. Trunk has the showcase app. The RTL stuff is in a patch that was posted to this list earlier and I added a few of my own tweaks. But kudos really must to go to the GWT team for this. I just made sure the right thing happened for RTL text.

RTL is working off the locale. So as soon as you set the locale to, say, Arabic all the rtl magic kicks in. The idea is that the widgets should just work and all a developer would need to do is modify the CSS so that left indents are on the right, etc.

Adil

[jhulford]

I'm not sure why, but when you open the Arabic version of the List and
Menus -> Tree example and expand one of the tree leaves you get
horizontal sliders when they're not necesary (FF 2.0 Win). I didn't
see that happening in the default locale though..

[John LaBanca]

Adil -

Thanks for your work on the RTL stuff.  Converting the LTR version of the style sheet to RTL is annoying, and I forgot to do it before checking in the Showcase (which explains the differences between the normal and rtl version).  There are two types of "magic" going on with the Showcase.  One change is that the locale provides a method to determine if the language is RTL, so Widgets can make intelligent layout decisions.  The Showcase itself also does some magic in that if you load an RTL language, it adds the RTL versions of the style sheets to the application.  Ultimately, we'd like to bake this into the gwt.xml rules so the rtl style sheets are included by default.

--
Thanks,
John LaBanca
jlab...@google.com

[Adil Allawi]

jhulford: it is probably an error in my changes to the CSS - I have to edit a large CSS file to swap left indents to the right, etc. but I did not put any time into debugging it!

John: The work is my pleasure. I made some comments in a previous thread about what I did to get Showcase working - here.

I agree the style sheet work is annoying and I also came to the same idea that GWT ought to auto-select an rtl style sheet. But I think that it would be better that the developer should only need to put the differences in the rtl style sheet and not include a whole style sheet so that errors are less likely when changes are made. What would be cool is if the developer could make one style sheet with ltr and rtl elements in it and a GWT compiler would separate it for you.

Adil

[John Tamplin]

On Wed, Mar 19, 2008 at 11:42 AM, Adil Allawi <adil....@gmail.com> wrote:

I agree the style sheet work is annoying and I also came to the same idea that GWT ought to auto-select an rtl style sheet. But I think that it would be better that the developer should only need to put the differences in the rtl style sheet and not include a whole style sheet so that errors are less likely when changes are made. What would be cool is if the developer could make one style sheet with ltr and rtl elements in it and a GWT compiler would separate it for you.

I don't know if this is a good idea, but we could have a convention like /*-LTR-*/ and /*-RTL-*/ above rules that are pertinent for one or the other, and it could be automatically split when it is copied to the output directory.  I think you probably only want to have one file to download to minimize HTTP round trips, but I agree the programmer should not have to duplicate the bulk of their CSS rules.  We would still need a bit of extra work to load the right one based on the selected locale, but it shouldn't be hard.

--
John A. Tamplin
Software Engineer, Google

[Adil Allawi]

Hi John, your idea sounds good. It would be simpler to have a default style sheet and only tag the changes instead of having /*-LTR-*/ and /*-RTL-*/ one would only have /*-RTL-*/.

Another idea... It would be nice to tag by locale. So have, say, a tag /*-locale=ar-*/. In this way we could have custom css for any locale. I know this would be useful for other languages - for example Japanese sometimes handles emphasis by underlining or using a different font where English text would simply use bold. But I am not coding this :) so I would happy wish just the first point.

regards

Adil

[Ray Cromwell]

I'm not a big fan of using comments to do this, but I guess it would work. I think there are a couple of alternatives to consider:

1) Enhanced Version of StyleInjector that can do CSSJanus style modifications (http://google-opensource.blogspot.com/2008/03/cssjanus-helping-i18n-and-ltr-to-rtl.html)

2) Use custom CSS '@' rule (ignored browsers), e.g.

@Direction(RTL) {
   // CSS rules here
}

(blech!)

3) Use custom CSS Media Query/vendor extension (http://www.w3.org/TR/css3-mediaqueries/)
 I successfully used these as a mechanism to target dozens of mobile devices back in 2002 with server-side processing to split out the CSS style sheets.

Example syntax:
@media all and (direction:rtl) {

}

or
<link rel="stylesheet" media="all and (direction: rtl)">

or

@import url(foo.css) all and (direction: rtl)

The benefit of Media Queries is not only that they are standard, but they work syntactically in LINK, @import, @media, and other contexts.

Moreover, inevitably when you want to have GWT apps targeting iPhones, Android, and other mobile devices, or use special CSS stylesheets for A11y, Media Queries perform the same function. A GWT stylesheet processor could then compile separate stylesheets for ltr, rtl, mobile, and disabled users.

4) Use CSS selectors with custom pseudo classes

.gwt-Tree:rtl {

}

5) Use CSS selectors with attribute selector for DIR

.gwt-Tree[dir="rtl"] {

}


The Media Query syntax has the benefit of being easier to parse out without fully parsing all CSS. #5 has the benefit that it should 'work' even if you don't split the stylesheet.

-Ray

On Wed, Mar 19, 2008 at 10:45 AM, Adil Allawi <adil....@gmail.com> wrote:

Hi John, your idea sounds good. It would be simpler to have a default style sheet and only tag the changes instead of having /*-LTR-*/ and /*-RTL-*/ one would only have /*-RTL-*/.

Another idea... It would be nice to tag by locale. So have, say, a tag /*-locale=ar-*/. In this way we could have custom css for any locale. I know this would be useful for other languages - for example Japanese sometimes handles emphasis by underlining or using a different font where English text would simply use bold. But I am not coding this :) so I would happy wish just the first point.

regards

Adil

At 11:51 -0400 19/3/08, John Tamplin wrote:

[Adil Allawi]

I like CSS Janus. It does exactly what I did to modify the style sheets for Showcase. And the /*@noflip*/ comment is a good way of preventing the altering of specific lines. This could make a good starting point and then it can be extended if there are any use cases where more complexity is needed.

I think the most important thing is to have a single, main style sheet file otherwise the developer would have to keep several similar files up to date and this can introduce unnecessary problems.

Adil

[Rajeev Dayal]

Another idea that is on the table (though still very preliminary, and we may need another solution in the interim) is the idea of specifying CSS information using annotations, thereby allowing the CSS rules to be statically analyzed. A natural extension to this effort would be adding some sort of CSS annotation for RTL-specific rules that would replace their LTR equivalents.

On Wed, Mar 19, 2008 at 8:56 PM, Adil Allawi <adil....@gmail.com> wrote:

I like CSS Janus. It does exactly what I did to modify the style sheets for Showcase. And the /*@noflip*/ comment is a good way of preventing the altering of specific lines. This could make a good starting point and then it can be extended if there are any use cases where more complexity is needed.

I think the most important thing is to have a single, main style sheet file otherwise the developer would have to keep several similar files up to date and this can introduce unnecessary problems.

Adil

At 11:38 -0700 19/3/08, Ray Cromwell wrote:

[John Tamplin]

On Thu, Mar 20, 2008 at 10:58 AM, Rajeev Dayal <rda...@google.com> wrote:

Another idea that is on the table (though still very preliminary, and we may need another solution in the interim) is the idea of specifying CSS information using annotations, thereby allowing the CSS rules to be statically analyzed. A natural extension to this effort would be adding some sort of CSS annotation for RTL-specific rules that would replace their LTR equivalents.

That would make it hard to use external tools to do the styling.  At least if we stick with reasonably "standard" approaches, there is a decent chance the tools can still be used.

[Isaac Truett]

Maybe I'm missing something, but it seems to me that standard CSS
gives you everything you need to do RTL/LTR styling without
interpreted comments or extensions.

1. Set a style on the <body> (or whatever wraps the section requiring
directionality) and use descendant selectors:

.MyWidget { /* Style my widget regardless of direction */ }
.gwt-I18N-RTL .MyWidget { /* Style my widget right-to-left */ }
.gwt-I18N-LTR .MyWidget { /* Style my widget left-to-right */ }

Or 2. Use GWT's dependent styles:

.MyWidget { /* Style my widget regardless of direction */ }
.MyWidget-gwt-I18N-RTL { /* Style my widget right-to-left */ }
.MyWidget-.gwt-I18N-LTR { /* Style my widget left-to-right */ }

Total: $0.02
Cash: $0.02

Thank you...

- Isaac

[Ray Cromwell]

Assuming proper CSS browser support, you don't need the descendant selection, you can just match against the DIR attribute, e.g.

.MyWidget[dir="rtl"] {...}

Or you could  combine the two approaches and use a match against dir on a parent element.  However, I think this would become tedious and I am starting favor the approach of letting a Janus-like processor automagically adjust the styles,while allowing you to blacklist which properties you don't want mucked with.

The blacklist approach seems less work than the whitelist approach of specifying all of the rules for each direction separately, although both techniques could be used, simply encode two separate LTR/RTL rules and blacklist them so that the RTL preprocessor won't muck with them.

Or support a global blacklist comment that disables an entire stylesheet from being processed.

-Ray

[Isaac Truett]

I don't think IE6 supports attribute selectors. I would love to be
wrong, of course.

My concern with a magical processor would be that it introduces a
compile step into the business of style tweaking. With a straight CSS
solution, I can modify styles and see results in real time. I've never
done an RTL app, but I imagine I would want to tweak something for one
directionality, then switch to the other and make sure it still looks
right with my tweak. Requiring an extra compile step would slow things
down considerably.

- Isaac

[Ray Cromwell]

Yeah, I think you're right. I try to keep IE6 as a bad memory, I'm hoping to go away so I can reclaim the storage in those neurons for other more useful activities. My original proposal was to handle these in a preprocessing step so that browser differences wouldn't matter. I can see why one would want to avoid a preprocessor, but if someone is going to use an ImmutableResourrceBundle/StyleInjector, you'll have to go through the compile cycle anyway.  I do agree that it is nice, early on in development stages, to change the CSS and hit reload however.

-Ray

[Emily Crutcher]

You can also combine StyleInjector and LocaleInfo to dynamically select the correct style sheet. FastTree.java uses this technique.

        Cheers,

                Emily

--
"There are only 10 types of people in the world: Those who understand binary, and those who don't"

[Adil]

I just could not resist it - I have patched Showcase again to fix the
remaining RTL issues in Safari and Firefox. And you can see the
results here:

http://www.diwan.com/w/showcase/Showcase.html?locale=ar

Here are the issues that I noticed:

1/ Spurious scroll bars in the main tree menu

This was caused by a 'hidden' element that is created in the Tree
class called 'focusable' I believe it is used to handle events for the
tree. This causes two problems in RTL layout:
- It is initialized with an absolute position that causes Safari to
draw it outside the space for the tree when it is RTL. Giving it a
relative position fixes this.
- Firefox in all its wisdom gives it an outline width of 1 pixel. So
its frame is one pixel larger than the frame of the tree but this only
causes a problem when the layout is RTL. Setting the outline width to
zero also fixes the scrollbars appearing in menus in Firefox.

2/ RTL menus drawing slightly offset.

This is an error in the code to position the menu bar caused by the
decorations. I will pass on the fix to Rajeev.

3/ Animations scrolling to the left for RTL menus - that was a one-
line fix.

4/ fixed the location of the punctuation in the Arabic translations

All that is left is to create an RTL Rich Text editor and the features
are complete :).

Adil

[Ray Cromwell]

Good work. One last nit.

The RichTextArea appears insufficiently localized. The drop down menus are still in English for size/font/colors. Also, do Arabic applications traditionally localize icons like B, I, U?

-Ray

[Adil Allawi]

RichTextArea has not been localised for any of the languages in Showcase - not just Arabic. If look at the code there is a properties file but not translations. So I am guessing that this part is still a work in progress.

My own Arabic applications do have Arabic B, I and U icons. I guess, Japanese would have the same issue. I also wonder if Bold Italic and Underline are the same words in French? But I think this is simple as the icons belong to the application and can be changed as needed. One would just need to modify the RichTextToolbar class to be locale aware.

regards

Adil

[Rajeev Dayal]

Hey Adil,

Great work with finding these issues!

Can you send out a patch with the fixes?


Thanks,
Rajeev

[Adil Allawi]

Hi Rajeev,

My pleasure. Enclosed are all my diffs from the current trunk so it includes your bidi patch. Any problems integrating this, please do ping me. You should especially check my changes to fix the spurious scroll bars in Showcase. Look at my change to Tree.java. I changed the 'focusable' element position to relative and set the outline to zero. There may be a better way to fix this.

regards

Adil

[Rajeev Dayal]

Hi Adil,

As of a few minutes ago, your RTL changes have been committed. Specifically:

-fixes for spurious scrollbars in Tree samples in Showcase. I used your fix for FF (outline: 0), but in IE, I was able to solve this by setting zoom:1 on the Tree's element. This seems like something that generally needs to be done when working with position:relative in IE.

-punctuation fixes for Arabic text

-DecoratorPanel fixes (though John L did the same fixes, so he is the one that actually committed this)

-Setting LTR for CSS/Source Code/.. (John L also did a fix for this, so he did the commit)

-PopupPanel animation fix

-Overlapping MenuBar fix

Thanks again for your help. When you have a chance, please take a look at the latest trunk and see if I missed anything.



Rajeev

On Wed, Mar 26, 2008 at 2:28 PM, Adil Allawi <adil....@gmail.com> wrote:

Hi Rajeev,

My pleasure. Enclosed are all my diffs from the current trunk so it includes your bidi patch. Any problems integrating this, please do ping me. You should especially check my changes to fix the spurious scroll bars in Showcase. Look at my change to Tree.java. I changed the 'focusable' element position to relative and set the outline to zero. There may be a better way to fix this.

regards

Adil

At 1:47 -0400 26/3/08, Rajeev Dayal wrote:

[Adil Allawi]

Hi Rajeev,

Greetings from sunny Doha (I am currently on vacation). Overall this is looking really great. Here are my (minor) quibbles...

1/ The code sample in CWDictionaryExample should be made LTR and left-aligned.

2/ I get an error in the console window in hosted mode:

Getting bytecode for 'com.google.gwt.user.client.ui.TreeImagesRTL_generatedBundle'

[ERROR] Errors in 'jar:file:/Projects/gwt/trunk/build/staging/gwt-mac-0.0.0/gwt-user.jar!/com/google/gwt/user/client/ui/TreeImages.java'

[ERROR] Line 61:  The type TreeImagesRTL is already defined

Not sure if this is significant.

3/ I looked at GWT-default.rtl.css file and found it a little inconsistent with GWT-default.css. But none of the inconsistencies were visible in the current application (styling related to CwFrame which is no longer in Showcase).

Also I ran GWT-default.css through CSS Janus and compared the results with GWT-default.rtl.css. I noticed that there are a few cases where a left indent was not swapped with a right indent. But again it was not in CSS items that are visible in the application.

4/ All the cases where there are shadow effects - e.g. the Custom Buttons or the Stylesheet buttons - the shadows should not be reversed. It just looks odd.

5/ I looked at the punctuation in the translation and it needs more work. The comma (,) should be replaced with the Arabic comma (U+060C) but not everywhere as the comma is also used as a separator for lists. Also it has a lot of extra spaces where they are not needed - probably due to a bad habit of the translator.

Best regards

Adil

[Rajeev Dayal]

Hey Adil,

Thanks very much for taking a look at the latest bidi work (especially when you're on your vacation!). I hope that you're having a good time!

Here are my comments to your comments:

On Tue, Apr 8, 2008 at 4:45 PM, Adil Allawi <adil....@gmail.com> wrote:

Hi Rajeev,

Greetings from sunny Doha (I am currently on vacation). Overall this is looking really great. Here are my (minor) quibbles...

1/ The code sample in CWDictionaryExample should be made LTR and left-aligned.

Thanks, I'll take care of this.
 

2/ I get an error in the console window in hosted mode:

Getting bytecode for 'com.google.gwt.user.client.ui.TreeImagesRTL_generatedBundle'

[ERROR] Errors in 'jar:file:/Projects/gwt/trunk/build/staging/gwt-mac-0.0.0/gwt-user.jar!/com/google/gwt/user/client/ui/TreeImages.java'

[ERROR] Line 61:  The type TreeImagesRTL is already defined

Not sure if this is significant.

You know, I think I saw this at one point when testing, and I totally forgot about it. Thanks for the reminder. We definitely should not be generating an error in this case.

3/ I looked at GWT-default.rtl.css file and found it a little inconsistent with GWT-default.css. But none of the inconsistencies were visible in the current application (styling related to CwFrame which is no longer in Showcase).

Also I ran GWT-default.css through CSS Janus and compared the results with GWT-default.rtl.css. I noticed that there are a few cases where a left indent was not swapped with a right indent. But again it was not in CSS items that are visible in the application.

Ok. As you know, we have some future plans to come up with a way to re-use styles from the LTR version of the stylesheet in the RTL version. We'll work these issues out at that point.

4/ All the cases where there are shadow effects - e.g. the Custom Buttons or the Stylesheet buttons - the shadows should not be reversed. It just looks odd.

I'll take a look at this. I did not realize that we were reversing the shadows for Custom Buttons or the Stylesheet buttons. In the case of Menus and Popups, the drop-shadow always appears on the right-hand side, regardless of the directionality. Is this how drop-shadows should generally work?

5/ I looked at the punctuation in the translation and it needs more work. The comma (,) should be replaced with the Arabic comma (U+060C) but not everywhere as the comma is also used as a separator for lists. Also it has a lot of extra spaces where they are not needed - probably due to a bad habit of the translator.

If you have some time (when you're not on vacation, of course), would you mind helping out with the Arabic translation? The GWT team would really appreciate it :)!

Enjoy the rest of your vacation.


Rajeev

At 2:08 -0400 7/4/08, Rajeev Dayal wrote:

[John LaBanca]

Rajeev -

 

FYI - I've been updating the styles and ensuring that the RTL and LTR versions look good in all browsers.  Feel free to keep editing them as well, but we'll need to merge the changes at some point.

 

Also, the margin-left in the "* html" rules are used to shift the image over the correct sprite, and they should not be converted to margin-right.  Most of the other's should be converted.  Moving shadows to the right side of the popups might take a little work, but its definitely posssible.  I think we weren't sure where the shadows were supposed to go in RTL mode.

[Rajeev Dayal]

Hey John,

Thanks for the heads up. I haven't started editing anything as yet, but I'll keep in mind the fact that you're editing these styles as well.

I'll work with you on moving the shadows over to the left side in RTL mode.



Thanks,
Rajeev

[younes]

Bonjour adil,

je travaille actuelle sur un projet multinational, je suis entrain de
chercher une solution pour la langue arabe, j'ai pas encore commencé à
penser à la solution idéale.

Est ce que tu peux m'envoyer ton code source si c'est possible ton
projet eclipse?

je te mettrai en courant de ce que j'ai trouvé comme solution dés que
j'ai une idée sur la solution choisi.

Merci Adil.



On 18 mar, 23:52, Adil Allawi <adil.all...@gmail.com> wrote:
> Hi, I spent a little time getting Showcase working with its Arabic locale and thought you would like to see the results. I put the application here:
>
> http://www.diwan.com/w/showcase/Showcase.html?locale=ar
>
> Obviously there are a few bits to clean up, but already it is looking much better than any thing else available for Arabic out there. I think gwt 1.5 is going to be very cool.
>
> Most of the work was tidying the CSS and I made a small fix to the Decorator Panel class. My favourite feature are the animated menus and tree lists. I could play with those for hours.
>
> thanks and regards
>
> Adil

[younes]

hello,

I'am really afraid, i didn't know if you are understanding frensh or
not, so I 'an actually working on an international project , and i
need a solution for arabic language, I didnot begin yet to think about
the solution but i will do it.

Could you send me please you code (of eclipse if it's possible) ?

I will send you my solution if find a new one.

Thanks Adil

[Kelly Norton]

Move Shadows for RTL? Does light travel differently when you communicate in RTL languages? You guys probably want to confirm that this is actually necessary.

/kel

--
If you received this communication by mistake, you are entitled to one free ice cream cone on me. Simply print out this email including all relevant SMTP headers and present them at my desk to claim your creamy treat. We'll have a laugh at my emailing incompetence, and play a game of ping pong. (offer may not be valid in all States).

[Adil Allawi]

Hello Adil 2

This is the development version and not yet a final release. The Information on getting code to this version of GWT is available at:

http://code.google.com/webtoolkit/makinggwtbetter.html

But we are off topic for this list - I suggest you post other questions to me directly.

Adil 1

[Adil Allawi]

Kelly,

The light is already travelling differently - I was suggesting to put it back in the same place! To be specific the virtual UI light source is from the top left and shadows drop to the bottom right. For RTL the shadows should stay in the same place, but, in the current GWT Showcase implementation they are mirrored.

regards

Adil

[John LaBanca]

I've been working on a patch, and the shadows will be on the bottom-right in both LTR and RTL.  If this is the desired location, we should be in good shape.

On Tue, Apr 22, 2008 at 11:03 AM, Adil Allawi <adil....@gmail.com> wrote:

Kelly,

The light is already travelling differently - I was suggesting to put it back in the same place! To be specific the virtual UI light source is from the top left and shadows drop to the bottom right. For RTL the shadows should stay in the same place, but, in the current GWT Showcase implementation they are mirrored.

regards

Adil

At 10:53 -0400 22/4/08, Kelly Norton wrote:

--
Thanks,
John LaBanca
jlab...@google.com

[Kelly Norton]

Yeah, that seems right to me. I had incorrectly misread your conversation as you guys were trying to change the shadows for RTL. Intuitively, it seems like they should remain the same and it sounds like Adil confirmed that.

/kel

[Rajeev Dayal]

@Adil:

Looks like I misunderstood you. So, the shadows are mirrored currently? Is this problem visible in the current trunk, say, in the Menu portion of the Showcase?

I remember there was a time when the DecoratorPanel was flipping its column order, which led to the mirrored shadows. However, John has since fixed this problem (as did you, in a patch that you submitted). But, this was not even the ideal way in which you would display a 'flipped' drop-shadow. The shadow graphics would have to be redone in order to correctly simulate a light source from the top-right. But, since we've all agreed that the drop-shadows should always be on the right-hand side, I guess that point is moot.

@Kelly:

Good point, light doesn't travel differently and toilets do not flush backwards in RTL languages.

There an interesting 'drop-shadow' RTL bug that I noticed though, with menus. If you look at the Menu example in the Showcase, the vertical menus below the horizontal bar are slightly offset horizontally. However, if you look at the same example in RTL mode, you'll notice that the horizontal offset is more exaggerated. The reason has to do with the drop-shadow. I guess, in the RTL case, we should be positioning the menu based on its right edge WITHOUT the drop shadow.



Rajeev

On Tue, Apr 22, 2008 at 11:03 AM, Adil Allawi <adil....@gmail.com> wrote:

Kelly,

The light is already travelling differently - I was suggesting to put it back in the same place! To be specific the virtual UI light source is from the top left and shadows drop to the bottom right. For RTL the shadows should stay in the same place, but, in the current GWT Showcase implementation they are mirrored.

regards

Adil

At 10:53 -0400 22/4/08, Kelly Norton wrote:

[Adil Allawi]

Rajeev,

The  Menus are actually OK - its the 3D-effect buttons that are the problem. Look at the custom buttons page in English and Arabic locales. Or the custom buttons for switching styles at the top of the  page. The dark edges should always be to the bottom and right.

I also noticed the slight offset for the menus - but I do not know what can be done about it as it is caused by the CSS style so we cannot compensate programmatically.

regards

Adil

[John LaBanca]

Adil might be right.  We use border effects to make the button look depressed when it is being clicked, and those border effects are probably switched in RTL mode.  I recently changed the styes on the buttons (out for review), but I'll make sure that the buttons look correct before we ship.

 

Thanks for pointing this out Adil.  We really had no idea if shadows and the like should appear on the opposite side or on the same side.

On Tue, Apr 22, 2008 at 7:41 PM, Adil Allawi <adil....@gmail.com> wrote:

Rajeev,

The  Menus are actually OK - its the 3D-effect buttons that are the problem. Look at the custom buttons page in English and Arabic locales. Or the custom buttons for switching styles at the top of the  page. The dark edges should always be to the bottom and right.

I also noticed the slight offset for the menus - but I do not know what can be done about it as it is caused by the CSS style so we cannot compensate programmatically.

regards

Adil

At 5:59 -0400 22/4/08, Rajeev Dayal wrote:

[Adil Allawi]

At 10:48 -0400 17/4/08, Rajeev Dayal wrote:
>If you have some time (when you're not on vacation, of course), would you mind helping out with the Arabic translation? The GWT team would really appreciate it :)!

Hello Rajeev,

I see why you need help, it looks like Arabic was done using machine translation. I asked one of my programmers to help with this and enclosed is the new translation.

This brought up one issue in the way you handle translations. Arabic has a different comma character (U+060C). But GWT requires a comma as a separator for lists. It is difficult for a translator to know when a normal comma must be used or when he should use an Arabic comma.

Apart from this what if a text in a list needs a comma - how can a comma be entered so it is not picked up as a list separator?

regards

Adil

[John Tamplin]

On Thu, May 8, 2008 at 7:47 PM, Adil Allawi <adil....@gmail.com> wrote:

This brought up one issue in the way you handle translations. Arabic has a different comma character (U+060C). But GWT requires a comma as a separator for lists. It is difficult for a translator to know when a normal comma must be used or when he should use an Arabic comma.

We could make either usable as a separator (there are probably other common separators for other languages), but then either would have to be escaped if needed.
 

Apart from this what if a text in a list needs a comma - how can a comma be entered so it is not picked up as a list separator?

For Constants/ConstantsWithLookup property files that have comma-separated lists, commas intended to be part of the text are escaped with a backslash -- see the 1.4 docs for Constants.

[Rajeev Dayal]

Hey Adil,

Thanks so much for your help with this. I'll get the new translations committed shortly.


Rajeev

On Thu, May 8, 2008 at 7:47 PM, Adil Allawi <adil....@gmail.com> wrote:

At 10:48 -0400 17/4/08, Rajeev Dayal wrote:

>If you have some time (when you're not on vacation, of course), would you mind helping out with the Arabic translation? The GWT team would really appreciate it :)!

Hello Rajeev,

I see why you need help, it looks like Arabic was done using machine translation. I asked one of my programmers to help with this and enclosed is the new translation.

This brought up one issue in the way you handle translations. Arabic has a different comma character (U+060C). But GWT requires a comma as a separator for lists. It is difficult for a translator to know when a normal comma must be used or when he should use an Arabic comma.

Apart from this what if a text in a list needs a comma - how can a comma be entered so it is not picked up as a list separator?

regards

Adil

[Rajeev Dayal]

On Thu, May 8, 2008 at 8:01 PM, John Tamplin <j...@google.com> wrote:

On Thu, May 8, 2008 at 7:47 PM, Adil Allawi <adil....@gmail.com> wrote:

This brought up one issue in the way you handle translations. Arabic has a different comma character (U+060C). But GWT requires a comma as a separator for lists. It is difficult for a translator to know when a normal comma must be used or when he should use an Arabic comma.

We could make either usable as a separator (there are probably other common separators for other languages), but then either would have to be escaped if needed.

Is there a common separator that we could use across all languages? How about the pipe character?

[John Tamplin]

On Tue, May 13, 2008 at 12:12 PM, Rajeev Dayal <rda...@google.com> wrote:

Is there a common separator that we could use across all languages? How about the pipe character?

It seems a little late to change it at this point (we would definitely have to retain comma as a separator for backward compatibility).  I suspect there will be languages that use a locale-specific character instead of | and will have the same confusion as Arabic.  If we want something different, how about ASCII FS (field separator) -- you would have to use \x to get it though.

[Adil Allawi]

I don't think this is worth changing at this stage. The best thing for my project is to require all text commas to be escaped.

But, for the future....

What I noticed is an issue that will hit many Arabic translators. They will change the comma into Arabic commas which will break the properties file. For a translator the commas which are separators and commas which are part of the text may not be clear.

Also I have my own translation utility which parses the properties file and puts the individual Arabic texts in their own edit box. This is important for rtl languages as you want to see the Arabic text in its proper rtl context - to make sure brackets and colons, etc are in the right places. But this is made more difficult as my tool would have to distinguish between text-commas and comma-separators.

ASCII FS would not be a good separator as it is not usually a visible/type-able character in most text editors. Maybe the best solution would be a properties file parser that requires commas that are part of the text to be escaped.

Adil

[Rajeev Dayal]

Hey Adil,

This patch was committed as r2984.
Thanks for your help with this one!


Rajeev

On Thu, May 8, 2008 at 7:47 PM, Adil Allawi <adil....@gmail.com> wrote:

At 10:48 -0400 17/4/08, Rajeev Dayal wrote:

>If you have some time (when you're not on vacation, of course), would you mind helping out with the Arabic translation? The GWT team would really appreciate it :)!

Hello Rajeev,

I see why you need help, it looks like Arabic was done using machine translation. I asked one of my programmers to help with this and enclosed is the new translation.

This brought up one issue in the way you handle translations. Arabic has a different comma character (U+060C). But GWT requires a comma as a separator for lists. It is difficult for a translator to know when a normal comma must be used or when he should use an Arabic comma.