L20n/Features/Conditional blocks: Difference between revisions

no edit summary
(Created page with "== 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...")
 
No edit summary
 
(8 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.
Account confirmers, canmove, Confirmed users
2,357

edits