[Lift] Re: RTL Localization

2008-09-03 Thread Marius

Or one other solution would be that the link references in the page to
be generated by a snippet (perhaps a built in snippet) to reference
css per language. This has the advantages:

1. Not much changes on lift side .. so it seems simpler.
2. It will work even if the static resources (css, js,images) are
server by a frontend server with reverse proxy on it.

Br's,
Marius

On Sep 3, 10:06 am, Marius [EMAIL PROTECTED] wrote:
 On Sep 3, 9:05 am, Tim Perrett [EMAIL PROTECTED] wrote:

   ... it really depends on the specific situation. I'm not sure though
   in what extend this is a framework concern (other then load perhaps
   css and js per language just like templatea are ... like /styles/
   homepage_ar_SA.css and lift would automatically pick the right thing
   per language). It looks to me purely an application concern as the
   application is aware of its particularities. So forgive me for asking
   (... I know it's my fault if I wasn't reading your previous posts)
   what are the localization problems that you're trying to solve at the
   framework level?

  Indeed - now you come to mention it that would probably be the only
  thing i'd look to perhaps include. With the current localization
  system in place, its possible to localize the layout in ./templates-
  hidden right?

 Yeah or any other page fort hat matter not only the ones from
 templates-hidden.

 So I suppose there would be no extra work needed to

  bother localizing CSS as you could just do it explicitly within the
  template for a complex RTL language etc.

 That's true, but there might be situations where the differences
 between language A and language B are quite minor so one would use the
 exact same html (no language suffix) but the stylesheets might be
 slightly different. In such situations having css per language is quit
 useful. Implementing this requires two things:

 1. Tell lift that it needs to serve css resources ... using
 LiftRules.LiftRequestPf
 2. Implement a Lift.Rules.RewritePf or a DispatchPf ... but note that
 RewritePf is not called in S scope

 The two things above could probably wrapped into a single LiftRules
 call.

 Have fun !

 Br's,
 Marius



  Like I said, no real issue right now, this was more of a thats an
  interesting problem, how could it be delt with in the context of lift

  Cheers

  Tim
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[Lift] Re: RTL Localization

2008-09-02 Thread Marius

Hi Tim,

I've been working on RTL localization on my current job for Saudi-
Arabia (unfortunately not lift). Localization per-se was not a problem
but it was challenging to make coherent right to left. Putting
dir=RTL for html tag does not suffice most of the time especially
for complex pages). AFAIK what needs to be done:

1. Have your strings translated in the resource bundle files. (you may
want to run native2ascii over the translated strings)
2. In lift you can suffix your page with the locale info. For instance
if you have homepage.html, you can also have homepage_ar_SA.html and
if calculateLocale returns Locale(ar, SA) lift will pick the right
markup
3. Also you may want to use different CSS files for RTL and LTR as
some things will slightly change.
4. SOmetimes JS code needs to be aware ofthe rendering direction if
you're damically creating markup from JS.

Other then that good luck with UAT :)

P.S.
May I ask what difficulties are you facing with regards of
localization/internationalization?


Br's,
Marius

On Sep 2, 9:19 am, Tim Perrett [EMAIL PROTECTED] wrote:
 Hey chaps,

 Im currently out in israel right now, and something has just occurred
 to me: with languages like hebrew that scribe from right to left, as
 opposed to the latin left to right, how is that accommodated for
 within our current localization setup?

 I know few languages scribe RTL, but it seemed like an interesting
 technical problem!

 really have got to get on with my new localisation branch

 Cheers

 Tim
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[Lift] Re: RTL Localization

2008-09-02 Thread Marius



On Sep 2, 5:17 pm, Tim Perrett [EMAIL PROTECTED] wrote:
 Hey Marius,

  I've been working on RTL localization on my current job for Saudi-
  Arabia (unfortunately not lift). Localization per-se was not a problem
  but it was challenging to make coherent right to left. Putting
  dir=RTL for html tag does not suffice most of the time especially
  for complex pages).

 Yeah that was what I thought also... MS .net just appears to have
 dir=rtl and thats it. If I can achieve anything better than that
 then id be happy.

  AFAIK what needs to be done:

  1. Have your strings translated in the resource bundle files. (you may
  want to run native2ascii over the translated strings)
  2. In lift you can suffix your page with the locale info. For instance
  if you have homepage.html, you can also have homepage_ar_SA.html and
  if calculateLocale returns Locale(ar, SA) lift will pick the right
  markup
  3. Also you may want to use different CSS files for RTL and LTR as
  some things will slightly change.
  4. SOmetimes JS code needs to be aware ofthe rendering direction if
  you're damically creating markup from JS.

 Interesting, localizing style sheets is not something i'd thought of.
 This is probably a wider issue with localization in general (german
 long words etc). Any thoughts on how it could be included in our
 overall localization strategy?

Localization to many languages for sure brings certain challenges as
the phrases will have different lengths and this would likely impact
the page look especially if you have strict requirements from UI
people (sometimes this just happens). The only ways to solve these
kind of things typically are:
1. Make the translation people aware of such things and re-
translations are sometimes needed
2. Apply certain deviations per language to accommodate such things.

... it really depends on the specific situation. I'm not sure though
in what extend this is a framework concern (other then load perhaps
css and js per language just like templatea are ... like /styles/
homepage_ar_SA.css and lift would automatically pick the right thing
per language). It looks to me purely an application concern as the
application is aware of its particularities. So forgive me for asking
(... I know it's my fault if I wasn't reading your previous posts)
what are the localization problems that you're trying to solve at the
framework level?


  May I ask what difficulties are you facing with regards of
  localization/internationalization?

 No problems as yet - just seemed like an interesting problem to solve
 thats all. Myself and Viktor are working on the localization branch
 (well, should be, but were both quite busy right now) so sometime,
 somewhen in the future I want to get that finished so we have a super-
 duper localization system.

 Cheers

 Tim
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---