L20n/Features/Conditional blocks: Difference between revisions

From MozillaWiki
< L20n‎ | Features
Jump to navigation Jump to search
No edit summary
 
(7 intermediate revisions by 2 users not shown)
Line 1: Line 1:
[[Category:L20n Features|{{SUBPAGENAME}}]]
[[Category:L20n]] __NOTOC__
== goal ==
== goal ==


Line 11: Line 14:
For the block cases, the syntax might look similar to this:
For the block cases, the syntax might look similar to this:
<pre>
<pre>
@block (@width<600) {
if (@width<600 && @locale="pl") {
   <title "Short text">
   <title "Short text">
   <windowDesc "About this app">
   <windowDesc "About this app">
}
}
</pre>
</pre>
of course it's entirely possible to achieve the same with index and globals:
of course it's entirely possible to achieve the same with index and globals:
<pre>
<pre>
<title[@width<600 ? 'long' : 'short'] {
<title[@width<600 ? 'long' : 'short'] {
Line 23: Line 28:
}>
}>
</pre>
</pre>
This syntax would also allow for @import commands to be encapsulated within such a conditional block.


Alternatively, we may just add an if clause to @import command:
This syntax would also allow for [[L20n/Features/Import|import command]] to be encapsulated within such a conditional block.
<pre>
 
@import ("path/to/resource") if (@width<600)
== discussion ==
</pre>


== status ==
Conditional blocks are at odds with completeness checking.  One solution might be to require that the entities in a block are also defined in their default form outside of the block.  In this scenario, it might even make sense to use a different keyword, like <code>overload</code> instead of <code>if</code>.
* stas - against
* gandalf - against
* pike - ?


We evaluated this proposal and so far we're leaning against adding the scope block. Adding another concept to L20n - conditional blocks,
We want to see if there will be a need for grouping variations of entities under a condition.  For now, we propose to put this feature on hold. Indexes (like <code>title[@width<600 ? 'long' : 'short']</code>) give us the same functionality and actually have a nice feature to them: the entity is defined in one place only.
would decrease the readability of the file (the reader would have to understand the scope syntax here), and
since the goal is achievable with index conditions, we plan not to implement it for 1.0.


If in the future we will see such conditional indexes to be widely used, we may decide to include it for the next version.
== status ==
* stas - put on hold
* gandalf - for (as @overload)
* pike - against
* code in [https://github.com/zbraniecki/l20n/tree/statements branch "statements"]


We plan to implement the if clause for @import command. This will also mean that we encourage groups of entities that are to be used in certain
This is needed for multilocale resources (Gaia)
conditions to be exported into a separate file. This should increase readability and will allow us to avoid increasing complexity.

Latest revision as of 20:02, 7 August 2012


goal

allow for entities to be enabled only for some screen sizes, operating systems, languages etc.

examples

Basically there are two concepts here. One is to group a list of entities into some form of "if" block, another is to make @import command work only when a pattern matches.

Use cases here are entities that are used only for a given operating system (mac or win only), or different entities for different screen sizes (if screen width is below 480, use shorter entities).

For the block cases, the syntax might look similar to this:

if (@width<600 && @locale="pl") {
  <title "Short text">
  <windowDesc "About this app">
}

of course it's entirely possible to achieve the same with index and globals:

<title[@width<600 ? 'long' : 'short'] {
  short: "Settings",
  long: "Settings Manager"
}>

This syntax would also allow for import command to be encapsulated within such a conditional block.

discussion

Conditional blocks are at odds with completeness checking. One solution might be to require that the entities in a block are also defined in their default form outside of the block. In this scenario, it might even make sense to use a different keyword, like overload instead of if.

We want to see if there will be a need for grouping variations of entities under a condition. For now, we propose to put this feature on hold. Indexes (like title[@width<600 ? 'long' : 'short']) give us the same functionality and actually have a nice feature to them: the entity is defined in one place only.

status

This is needed for multilocale resources (Gaia)