CSS Selector Localizations: A New idea from the Farmdawg Idea Factory

[Matt Farmer]

So, earlier this week I was brainstorming localizations.

Exciting topic, I know.

I was brainstorming them because I've realized that they're kind of a royal pain in their current implementation. From what I've seen you have two options for localizations:

1. Localize an entire template and repeat a whole bunch of markup.
2. Use a messages.properties file and pepper localization keys throughout your code.

I was left wondering if there wasn't A Better Way™ to do localizations across an entire app, and I wanted to brainstorm with the rest of you guys and see if I could get some feedback on what I've been rolling around in my head. My primary goal in this is to get rid of the two options above entirely. What I'd love is a framework though with we could change the content of what appears on the page, using the actual content of the markup itself. I hear these style sheets that cascade are all the rage amongst the youngsters these days, and they have these "selectors" that let you pick what style in your sheet applies where.

Genius, amirite?

My thoughts are that we could use these "selectors" to "select" the "content" on the "page." Essentially, localization would become completely separate from the actual structural HTML. No more peppering localization keys about your code.

So where we currently have.

key1=value1
key2=value2
key3=value3

We could have

header h1=value1
.intro-text=value2
.pricing-description .first-paragraph=value3
.pricing-description .second-paragraph=value4

Or, perhaps, take a page from the SASS playbook:

header h1
  "value1"


.intro-text
  "value2"


.pricing-description.pricing-description
  .first-paragraph
    "value3"


  .second-paragraph
    "value4"

So, yeah, I wanted to get some thoughts around this. What do you guys think? I'm going to continue bouncing it around in my head throughout the next few weeks, so let me know. :)

Matt

[Diego Medina]

Interesting idea,  a few questions:

Are you thinking of using the same css parser that we use in snippets? I would like that because I then don't need to learn or restrictwhat I can use.  On the other hand,  it would mean seeing a lot of .h1 * (the asterisk to indicate the child of the node)

How would you tell lift which page uses which translations.  I can see having a lot of h1 but with different content on different pages.

And one more but I forgot it :)

Thanks

Diego

Sent from my tablet
Diego

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code
 
---
You received this message because you are subscribed to the Google Groups "Lift" group.
To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Antonio Salazar Cardozo]

I think it's reasonable to reuse the existing selector implementation, but my thought is maybe in this context you'd terminate in nothing if you wanted to do the contents of the node, and terminate with a sigil of some sort if you wanted to replace the element, rather than the other way around. That makes more sense in this context.

One advantage of this approach is that it also encourages proper, semantically valuable names for classes and such, since localizers will need those to understand what they're trying to translate. It also opens up the possibility of some interesting tooling around Lift i18n, given that those same selectors can also be applied browser-side, say in a system that highlights localizable elements on the page and lets you input your localizations and then produces the appropriate file.

For resolving which file's localizations would apply, I think some sort of cascading mechanism would make sense. There's already some logic in that regard in the Java ResourceBundle, and I think it cascades both based on locale/language and on certain path attributes. I was reading the docs earlier but don't recall the specifics. Regardless, I can see a setup where you would have a chain based on directory structure, e.g. given a file src/main/webapp/users/profile.html, you might have a root.localize, root.users.localize, and root.users.profile.localize file (obviously made up the file extension). You could run the localizations in each of these files from most specific to least specific.

The key problem that still remains in this situation is that a theoretical root.localize might have a lot of general rules, most of which don't apply to a particular page, so going through all of them might be a little more than annoying. Some sort of include mechanism might work better in that situation. I think that's something to consider further down the path after a proof of concept though, personally.

I think we're still just scratching the surface of the awesome possibilities that CSS selector transforms really give us. This sounds like an awesome idea.

Thanks,

Antonio

[Diego Medina]

I definitely like the idea of changing the selector rules a little bit to accommodate for the most common case (so snippet rules and i18 rules would be almost the same, but not 100%.

To solve the issue of which i18 rules apply to which page, what do you think of using the same idea of how we invoke snippets?

So on my profile.html file, I could have some tag that will either list all the 18n files it should use as one attribute, or a series of tags. In other words:

<div data-lift="Loc2=root,users,profile"></div>

Wait, if we use a tag like this one, it would be as simple as adding a new built-in snippet that could read the list of css selectors => translations, and apply them to the html

I think we're still just scratching the surface of the awesome possibilities that CSS selector transforms really give us. This sounds like an awesome idea.

+1

Thanks

  Diego

--
Diego Medina
Lift/Scala Developer
di...@fmpwizard.com
http://fmpwizard.telegr.am

[Matt Farmer]

I think the best way to handle the different pages rule is going to be to apply semantic ID's to the body tags of the pages, and then scope your localizations relative to those.

Matt

[Diego Medina]

so what body id would you use for a profile page, which you would like to inherit root and users i18n rules ?

On Mon, Jul 15, 2013 at 10:09 AM, Matt Farmer <ma...@frmr.me> wrote:

I think the best way to handle the different pages rule is going to be to apply semantic ID's to the body tags of the pages, and then scope your localizations relative to those.

Matt

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

---
You received this message because you are subscribed to the Google Groups "Lift" group.

To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Matt Farmer]

Uh, #profile-page? What do you mean by root and user's i18n rules? Picking what localization to apply works the same as it always would…

--

Matt Farmer

You received this message because you are subscribed to a topic in the Google Groups "Lift" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/liftweb/ER3M49LHypY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to liftweb+u...@googlegroups.com.

[Antonio Salazar Cardozo]

I think the benefit of this approach is that it avoids polluting the markup too much, as well as avoiding having to come up with weird keys to describe the i18n entries.

In my mind, we could provide something like you suggest for explicitly specifying a cascade of i18n, but have a sane default like the one I've suggested.

Thanks,

Antonio 

[Diego Medina]

sounds good, when do we see this prototype? :)

[Peter Petersson]

Interesting idea!

As I understand the ide wouldn�t using "selectors" potentially tie the localized content (part i.e the key value) to the markup structure and or "selector" path ? Couldn�t that be a problem

For example

header h1=value1

would as I understand it select and replace the content in the first "h1" inside "header", this would mean that if a designer changes the "h1" to a "h2" (his concern) he should also make sure that the localization "value lookup" specification should be changed (not his concern) or there has to be some mechanism that makes sure that the localized value is not lost.
A parser that warns or highlights or even change the binding could amend this but that's not so trivial is it.


Still you could be on to something really nice here.
Wouldn�t it be a idea to keep the standard resource file structure for the key value pairs and make the key a mapping value introducing a mapping "localization selector mapping" file (i.e value1 above would instead be the key1 (in the resource file below) and as such correspond to a mapping in the resource file) for instance like the combined lang structure below (or the ones having suffixes based on the Locale)

<?xml version="1.0"?>
<resources>
�� <res name="key1" lang="en" default="true">value1a</res>
�� <res name="key1" lang="en" country="US" >value1b</res>
�� <res name="key1" lang="sv">value1c</res>
�� <res name="key1" lang="no">value1d</res>
�� :
</resources>

in file
_resource_xxxx.html
_resource_xxxx_mapping.html

The reason for this that the translator may use a tool that aids him in the translation work based on this structure (although i don't know if this is something common) anyway the file needs to be suitable for export/import processing and or easy to work with for the translator.� � �

Another reason for keeping the structure is that it could potentially make it possible to gradually adopt the selector mapping scheme.

I am just throwing things out here ;)� �

best regards Peter Petersson

On 07/15/2013 01:31 AM, Matt Farmer wrote:

So, earlier this week I was brainstorming localizations.

Exciting topic, I know.

I was brainstorming them because I've realized that they're kind of a royal pain in their current implementation. From what I've seen you have two options for localizations:

1. Localize an entire template and repeat a whole bunch of markup.
2. Use a messages.properties file and pepper localization keys throughout your code.

I was left wondering if there wasn't A Better Way� to do localizations across an entire app, and I wanted to brainstorm with the rest of you guys and see if I could get some feedback on what I've been rolling around in my head. My primary goal in this is to get rid of the two options above entirely. What I'd love is a framework though with we could change the content of what appears on the page, using the actual content of the markup itself. I hear these style sheets that cascade are all the rage amongst the youngsters these days, and they have these "selectors" that let you pick what style in your sheet applies where.

Genius, amirite?

My thoughts are that we could use these "selectors" to "select" the "content" on the "page." Essentially, localization would become completely separate from the actual structural HTML. No more peppering localization keys about your code.

So where we currently have.

key1=value1
key2=value2
key3=value3

We could have

header h1=value1
.intro-text=value2
.pricing-description .first-paragraph=value3
.pricing-description .second-paragraph=value4

Or, perhaps, take a page from the SASS playbook:

header h1
� "value1"


.intro-text
� "value2"


.pricing-description.pricing-description
� .first-paragraph
� � "value3"


� .second-paragraph
� � "value4"

So, yeah, I wanted to get some thoughts around this. What do you guys think? I'm going to continue bouncing it around in my head throughout the next few weeks, so let me know. :)

Matt

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

�

---
You received this message because you are subscribed to the Google Groups "Lift" group.
To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

�
�