tweaked doc markup

doc/advanced.rst

@@ -40,7 +40,7 @@ generate).
 
 You can use a ``lipsum`` *tag*:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% lipsum 40 %}
 
@@ -51,7 +51,7 @@ three main reasons:
 * The tag outputs something;
 * The tag is not flexible as you cannot use it in an expression:
 
-  .. code-block:: jinja
+  .. code-block:: twig
 
       {{ 'some text' ~ {% lipsum 40 %} ~ 'some more text' }}
 
@@ -60,7 +60,7 @@ the most complex extension point of Twig.
 
 Now, let's use a ``lipsum`` *filter*:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ 40|lipsum }}
 
@@ -71,14 +71,14 @@ transform).
 
 Next, let's use a ``lipsum`` *function*:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ lipsum(40) }}
 
 Here we go. For this specific example, the creation of a function is the
 extension point to use. And you can use it anywhere an expression is accepted:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ 'some text' ~ lipsum(40) ~ 'some more text' }}
 
@@ -87,7 +87,7 @@ extension point to use. And you can use it anywhere an expression is accepted:
 Last but not the least, you can also use a *global* object with a method able
 to generate lorem ipsum text:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ text.lipsum(40) }}
 
@@ -119,7 +119,7 @@ available in all templates and macros::
 
 You can then use the ``text`` variable anywhere in a template:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ text.lipsum(40) }}
 
@@ -156,7 +156,7 @@ Then, add the filter to your Twig environment::
 
 And here is how to use it in a template:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ 'Twig'|rot13 }}
 
@@ -168,7 +168,7 @@ to the filter (within parentheses ``()``) as extra arguments.
 
 For instance, the following code:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ 'TWIG'|lower }}
     {{ now|date('d/m/Y') }}
@@ -364,7 +364,7 @@ The above example shows how you can create tests that use a node class. The
 node class has access to one sub-node called 'node'. This sub-node contains the
 value that is being tested. When the ``odd`` filter is used in code such as:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% if my_value is odd %}
 
@@ -395,14 +395,14 @@ Most of the time though, a tag is not needed:
   For instance, if you want to create a tag that converts a Markdown formatted
   text to HTML, create a ``markdown`` filter instead:
 
-  .. code-block:: jinja
+  .. code-block:: twig
 
       {{ '**markdown** text'|markdown }}
 
   If you want use this filter on large amounts of text, wrap it with the
   :doc:`apply <tags/apply>` tag:
 
-  .. code-block:: jinja
+  .. code-block:: twig
 
       {% apply markdown %}
       Title
@@ -423,7 +423,7 @@ Most of the time though, a tag is not needed:
   For instance, if you want to create a tag that logs text, create a ``log``
   function instead and call it via the :doc:`do <tags/do>` tag:
 
-  .. code-block:: jinja
+  .. code-block:: twig
 
       {% do log('Log some things') %}
 
@@ -432,7 +432,7 @@ If you still want to create a tag for a new language construct, great!
 Let's create a simple ``set`` tag that allows the definition of simple
 variables from within a template. The tag can be used like follows:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% set name = "value" %}
 

doc/advanced_legacy.rst

@@ -41,7 +41,7 @@ generate).
 
 You can use a ``lipsum`` *tag*:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% lipsum 40 %}
 
@@ -52,7 +52,7 @@ three main reasons:
 * The tag outputs something;
 * The tag is not flexible as you cannot use it in an expression:
 
-  .. code-block:: jinja
+  .. code-block:: twig
 
       {{ 'some text' ~ {% lipsum 40 %} ~ 'some more text' }}
 
@@ -61,7 +61,7 @@ the most complex extension point of Twig.
 
 Now, let's use a ``lipsum`` *filter*:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ 40|lipsum }}
 
@@ -72,14 +72,14 @@ transform).
 
 Next, let's use a ``lipsum`` *function*:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ lipsum(40) }}
 
 Here we go. For this specific example, the creation of a function is the
 extension point to use. And you can use it anywhere an expression is accepted:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ 'some text' ~ ipsum(40) ~ 'some more text' }}
 
@@ -88,7 +88,7 @@ extension point to use. And you can use it anywhere an expression is accepted:
 Last but not the least, you can also use a *global* object with a method able
 to generate lorem ipsum text:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ text.lipsum(40) }}
 
@@ -120,7 +120,7 @@ available in all templates and macros::
 
 You can then use the ``text`` variable anywhere in a template:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ text.lipsum(40) }}
 
@@ -134,7 +134,7 @@ arguments passed to the filter (within parentheses ``()``) as extra arguments.
 Defining a filter is as easy as associating the filter name with a PHP
 callable. For instance, let's say you have the following code in a template:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ 'TWIG'|lower }}
 
@@ -152,7 +152,7 @@ function.
 
 A filter can also take extra arguments like in the following example:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ now|date('d/m/Y') }}
 
@@ -169,7 +169,7 @@ In this section, we will create a ``rot13`` filter, which should return the
 `rot13`_ transformation of a string. Here is an example of its usage and the
 expected output:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ "Twig"|rot13 }}
 
@@ -188,7 +188,7 @@ of the PHP function to call, here ``str_rot13``, a native PHP function.
 
 Let's say I now want to be able to add a prefix before the converted string:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ "Twig"|rot13('prefix_') }}
 
@@ -297,7 +297,7 @@ Functions
 A function is a regular PHP function or an object method that can be called from
 templates.
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ constant("DATE_W3C") }}
 
@@ -368,7 +368,7 @@ feature as you need to understand how Twig's internals work.
 Let's create a simple ``set`` tag that allows the definition of simple
 variables from within a template. The tag can be used like follows:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% set name = "value" %}
 

doc/api.rst

@@ -384,7 +384,7 @@ output escaping strategy::
 If set to ``html``, all variables in templates are escaped (using the ``html``
 escaping strategy), except those using the ``raw`` filter:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ article.to_html|raw }}
 
@@ -392,7 +392,7 @@ You can also change the escaping mode locally by using the ``autoescape`` tag
 (see the :doc:`autoescape<tags/autoescape>` doc for the syntax used before
 Twig 1.8):
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% autoescape 'html' %}
         {{ var }}
@@ -409,7 +409,7 @@ The escaping rules are implemented as follows:
 * Literals (integers, booleans, arrays, ...) used in the template directly as
   variables or filter arguments are never automatically escaped:
 
-  .. code-block:: jinja
+  .. code-block:: twig
 
         {{ "Twig<br />" }} {# won't be escaped #}
 
@@ -419,7 +419,7 @@ The escaping rules are implemented as follows:
 * Expressions which the result is always a literal or a variable marked safe
   are never automatically escaped:
 
-  .. code-block:: jinja
+  .. code-block:: twig
 
         {{ foo ? "Twig<br />" : "<br />Twig" }} {# won't be escaped #}
 
@@ -434,13 +434,13 @@ The escaping rules are implemented as follows:
 
 * Escaping is applied before printing, after any other filter is applied:
 
-  .. code-block:: jinja
+  .. code-block:: twig
 
         {{ var|upper }} {# is equivalent to {{ var|upper|escape }} #}
 
 * The `raw` filter should only be used at the end of the filter chain:
 
-  .. code-block:: jinja
+  .. code-block:: twig
 
         {{ var|raw|upper }} {# will be escaped #}
 
@@ -451,7 +451,7 @@ The escaping rules are implemented as follows:
   ``escape('html')`` are marked safe for HTML, ``escape('js')`` is marked
   safe for JavaScript, ``raw`` is marked safe for everything.
 
-  .. code-block:: jinja
+  .. code-block:: twig
 
         {% autoescape 'js' %}
             {{ var|escape('html') }} {# will be escaped for HTML and JavaScript #}
@@ -501,7 +501,7 @@ The policy object is the first argument of the sandbox constructor::
 By default, the sandbox mode is disabled and should be enabled when including
 untrusted template code by using the ``sandbox`` tag:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% sandbox %}
         {% include 'user.html' %}

doc/coding_standards.rst

@@ -7,7 +7,7 @@ standards:
 * Put one (and only one) space after the start of a delimiter (``{{``, ``{%``,
   and ``{#``) and before the end of a delimiter (``}}``, ``%}``, and ``#}``):
 
-  .. code-block:: jinja
+  .. code-block:: twig
 
     {{ foo }}
     {# comment #}
@@ -16,7 +16,7 @@ standards:
   When using the whitespace control character, do not put any spaces between
   it and the delimiter:
 
-  .. code-block:: jinja
+  .. code-block:: twig
 
     {{- foo -}}
     {#- comment -#}
@@ -28,7 +28,7 @@ standards:
   operators (``not``, ``and``, ``or``), ``~``, ``is``, ``in``, and the ternary
   operator (``?:``):
 
-  .. code-block:: jinja
+  .. code-block:: twig
 
      {{ 1 + 2 }}
      {{ foo ~ bar }}
@@ -37,7 +37,7 @@ standards:
 * Put one (and only one) space after the ``:`` sign in hashes and ``,`` in
   arrays and hashes:
 
-  .. code-block:: jinja
+  .. code-block:: twig
 
      {{ [1, 2, 3] }}
      {{ {'foo': 'bar'} }}
@@ -45,13 +45,13 @@ standards:
 * Do not put any spaces after an opening parenthesis and before a closing
   parenthesis in expressions:
 
-  .. code-block:: jinja
+  .. code-block:: twig
 
     {{ 1 + (2 * 3) }}
 
 * Do not put any spaces before and after string delimiters:
 
-  .. code-block:: jinja
+  .. code-block:: twig
 
     {{ 'foo' }}
     {{ "foo" }}
@@ -59,7 +59,7 @@ standards:
 * Do not put any spaces before and after the following operators: ``|``,
   ``.``, ``..``, ``[]``:
 
-  .. code-block:: jinja
+  .. code-block:: twig
 
     {{ foo|upper|lower }}
     {{ user.name }}
@@ -69,7 +69,7 @@ standards:
 * Do not put any spaces before and after the parenthesis used for filter and
   function calls:
 
-  .. code-block:: jinja
+  .. code-block:: twig
 
      {{ foo|default('foo') }}
      {{ range(1..10) }}
@@ -77,14 +77,14 @@ standards:
 * Do not put any spaces before and after the opening and the closing of arrays
   and hashes:
 
-  .. code-block:: jinja
+  .. code-block:: twig
 
      {{ [1, 2, 3] }}
      {{ {'foo': 'bar'} }}
 
 * Use lower cased and underscored variable names:
 
-  .. code-block:: jinja
+  .. code-block:: twig
 
      {% set foo = 'foo' %}
      {% set foo_bar = 'foo' %}
@@ -92,7 +92,7 @@ standards:
 * Indent your code inside tags (use the same indentation as the one used for
   the target language of the rendered template):
 
-  .. code-block:: jinja
+  .. code-block:: twig
 
      {% block foo %}
          {% if true %}

doc/filters/abs.rst

@@ -3,7 +3,7 @@
 
 The ``abs`` filter returns the absolute value.
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {# number = -5 #}
 

doc/filters/batch.rst

@@ -8,7 +8,7 @@ The ``batch`` filter "batches" items by returning a list of lists with the
 given number of items. A second parameter can be provided and used to fill in
 missing items:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% set items = ['a', 'b', 'c', 'd', 'e', 'f', 'g'] %}
 
@@ -24,7 +24,7 @@ missing items:
 
 The above example will be rendered as:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     <table>
         <tr>

doc/filters/capitalize.rst

@@ -4,7 +4,7 @@
 The ``capitalize`` filter capitalizes a value. The first character will be
 uppercase, all others lowercase:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ 'my first car'|capitalize }}
 

doc/filters/convert_encoding.rst

@@ -8,7 +8,7 @@ The ``convert_encoding`` filter converts a string from one encoding to
 another. The first argument is the expected output charset and the second one
 is the input charset:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ data|convert_encoding('UTF-8', 'iso-2022-jp') }}
 

doc/filters/date.rst

@@ -15,7 +15,7 @@
 
 The ``date`` filter formats a date to a given format:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ post.published_at|date("m/d/Y") }}
 
@@ -27,14 +27,14 @@ The ``date`` filter accepts strings (it must be in a format supported by the
 `strtotime`_ function), `DateTime`_ instances, or `DateInterval`_ instances. For
 instance, to display the current date, filter the word "now":
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ "now"|date("m/d/Y") }}
 
 To escape words and characters in the date format use ``\\`` in front of each
 character:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ post.published_at|date("F jS \\a\\t g:ia") }}
 
@@ -42,7 +42,7 @@ If the value passed to the ``date`` filter is ``null``, it will return the
 current date by default. If an empty string is desired instead of the current
 date, use a ternary operator:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ post.published_at is empty ? "" : post.published_at|date("m/d/Y") }}
 
@@ -66,14 +66,14 @@ By default, the date is displayed by applying the default timezone (the one
 specified in php.ini or declared in Twig -- see below), but you can override
 it by explicitly specifying a timezone:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ post.published_at|date("m/d/Y", "Europe/Paris") }}
 
 If the date is already a DateTime object, and if you want to keep its current
 timezone, pass ``false`` as the timezone value:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ post.published_at|date("m/d/Y", false) }}
 

doc/filters/date_modify.rst

@@ -6,7 +6,7 @@
 
 The ``date_modify`` filter modifies a date with a given modifier string:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ post.published_at|date_modify("+1 day")|date("m/d/Y") }}
 

doc/filters/default.rst

@@ -4,7 +4,7 @@
 The ``default`` filter returns the passed default value if the value is
 undefined or empty, otherwise the value of the variable:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ var|default('var is not defined') }}
 
@@ -18,7 +18,7 @@ When using the ``default`` filter on an expression that uses variables in some
 method calls, be sure to use the ``default`` filter whenever a variable can be
 undefined:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ var.method(foo|default('foo'))|default('foo') }}
 

doc/filters/escape.rst

@@ -13,7 +13,7 @@ context.
 
 By default, it uses the HTML escaping strategy:
 
-.. code-block:: html+jinja
+.. code-block:: html+twig
 
     <p>
         {{ user.username|escape }}
@@ -21,7 +21,7 @@ By default, it uses the HTML escaping strategy:
 
 For convenience, the ``e`` filter is defined as an alias:
 
-.. code-block:: html+jinja
+.. code-block:: html+twig
 
     <p>
         {{ user.username|e }}
@@ -30,7 +30,7 @@ For convenience, the ``e`` filter is defined as an alias:
 The ``escape`` filter can also be used in other contexts than HTML thanks to
 an optional argument which defines the escaping strategy to use:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ user.username|e }}
     {# is equivalent to #}
@@ -38,7 +38,7 @@ an optional argument which defines the escaping strategy to use:
 
 And here is how to escape variables included in JavaScript code:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ user.username|escape('js') }}
     {{ user.username|e('js') }}
@@ -77,7 +77,7 @@ to learn more about this topic.
     escape filter; but that does not work when using a variable as the
     escaping strategy:
 
-    .. code-block:: jinja
+    .. code-block:: twig
 
         {% set strategy = 'html' %}
 
@@ -89,7 +89,7 @@ to learn more about this topic.
     When using a variable as the escaping strategy, you should disable
     automatic escaping:
 
-    .. code-block:: jinja
+    .. code-block:: twig
 
         {% set strategy = 'html' %}
 

doc/filters/first.rst

@@ -7,7 +7,7 @@
 The ``first`` filter returns the first "element" of a sequence, a mapping, or
 a string:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ [1, 2, 3, 4]|first }}
     {# outputs 1 #}

doc/filters/format.rst

@@ -4,7 +4,7 @@
 The ``format`` filter formats a given string by replacing the placeholders
 (placeholders follows the `sprintf`_ notation):
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ "I like %s and %s."|format(foo, "bar") }}
 

doc/filters/join.rst

@@ -7,7 +7,7 @@
 The ``join`` filter returns a string which is the concatenation of the items
 of a sequence:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ [1, 2, 3]|join }}
     {# returns 123 #}
@@ -15,7 +15,7 @@ of a sequence:
 The separator between elements is an empty string per default, but you can
 define it with the optional first parameter:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ [1, 2, 3]|join('|') }}
     {# outputs 1|2|3 #}
@@ -23,7 +23,7 @@ define it with the optional first parameter:
 A second parameter can also be provided that will be the separator used between
 the last two items of the sequence:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ [1, 2, 3]|join(', ', ' and ') }}
     {# outputs 1, 2 and 3 #}

doc/filters/json_encode.rst

@@ -3,7 +3,7 @@
 
 The ``json_encode`` filter returns the JSON representation of a value:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ data|json_encode() }}
 

doc/filters/keys.rst

@@ -4,7 +4,7 @@
 The ``keys`` filter returns the keys of an array. It is useful when you want to
 iterate over the keys of an array:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% for key in array|keys %}
         ...

doc/filters/last.rst

@@ -7,7 +7,7 @@
 The ``last`` filter returns the last "element" of a sequence, a mapping, or
 a string:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ [1, 2, 3, 4]|last }}
     {# outputs 4 #}

doc/filters/length.rst

@@ -16,7 +16,7 @@ it will return the length of the string provided by that method.
 
 For objects that implement the ``IteratorAggregate`` interface, ``length`` will use the return value of the ``iterator_count()`` method.
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% if users|length > 10 %}
         ...

doc/filters/lower.rst

@@ -3,7 +3,7 @@
 
 The ``lower`` filter converts a value to lowercase:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ 'WELCOME'|lower }}
 

doc/filters/merge.rst

@@ -3,7 +3,7 @@
 
 The ``merge`` filter merges an array with another array:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% set values = [1, 2] %}
 
@@ -15,7 +15,7 @@ New values are added at the end of the existing ones.
 
 The ``merge`` filter also works on hashes:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% set items = { 'apple': 'fruit', 'orange': 'fruit', 'peugeot': 'unknown' } %}
 
@@ -32,7 +32,7 @@ overridden.
     If you want to ensure that some values are defined in an array (by given
     default values), reverse the two elements in the call:
 
-    .. code-block:: jinja
+    .. code-block:: twig
 
         {% set items = { 'apple': 'fruit', 'orange': 'fruit' } %}
 

doc/filters/nl2br.rst

@@ -6,7 +6,7 @@
 
 The ``nl2br`` filter inserts HTML line breaks before all newlines in a string:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ "I like Twig.\nYou will like it too."|nl2br }}
     {# outputs

doc/filters/number_format.rst

@@ -7,21 +7,21 @@
 The ``number_format`` filter formats numbers.  It is a wrapper around PHP's
 `number_format`_ function:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ 200.35|number_format }}
 
 You can control the number of decimal places, decimal point, and thousands
 separator using the additional arguments:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ 9800.333|number_format(2, '.', ',') }}
 
 To format negative numbers, wrap the number with parentheses (needed because of
 Twig's :ref:`precedence of operators <twig-expressions>`:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ -9800.333|number_format(2, '.', ',') }} {# outputs : -9 #}
     {{ (-9800.333)|number_format(2, '.', ',') }} {# outputs : -9,800.33 #}

doc/filters/raw.rst

@@ -5,7 +5,7 @@ The ``raw`` filter marks the value as being "safe", which means that in an
 environment with automatic escaping enabled this variable will not be escaped
 if ``raw`` is the last filter applied to it:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% autoescape %}
         {{ var|raw }} {# var won't be escaped #}
@@ -17,7 +17,7 @@ if ``raw`` is the last filter applied to it:
 
     Be careful when using the ``raw`` filter inside expressions:
 
-    .. code-block:: jinja
+    .. code-block:: twig
 
         {% autoescape %}
             {% set hello = '<strong>Hello</strong>' %}

doc/filters/replace.rst

@@ -4,7 +4,7 @@
 The ``replace`` filter formats a given string by replacing the placeholders
 (placeholders are free-form):
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ "I like %this% and %that%."|replace({'%this%': foo, '%that%': "bar"}) }}
 

doc/filters/reverse.rst

@@ -6,7 +6,7 @@
 
 The ``reverse`` filter reverses a sequence, a mapping, or a string:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% for user in users|reverse %}
         ...
@@ -21,7 +21,7 @@ The ``reverse`` filter reverses a sequence, a mapping, or a string:
     For sequences and mappings, numeric keys are not preserved. To reverse
     them as well, pass ``true`` as an argument to the ``reverse`` filter:
 
-    .. code-block:: jinja
+    .. code-block:: twig
 
         {% for key, value in {1: "a", 2: "b", 3: "c"}|reverse %}
             {{ key }}: {{ value }}

doc/filters/round.rst

@@ -6,7 +6,7 @@
 
 The ``round`` filter rounds a number to a given precision:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ 42.55|round }}
     {# outputs 43 #}

doc/filters/slice.rst

@@ -6,7 +6,7 @@
 
 The ``slice`` filter extracts a slice of a sequence, a mapping, or a string:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% for i in [1, 2, 3, 4, 5]|slice(1, 2) %}
         {# will iterate over 2 and 3 #}
@@ -18,7 +18,7 @@ The ``slice`` filter extracts a slice of a sequence, a mapping, or a string:
 
 You can use any valid expression for both the start and the length:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% for i in [1, 2, 3, 4, 5]|slice(start, length) %}
         {# ... #}
@@ -26,7 +26,7 @@ You can use any valid expression for both the start and the length:
 
 As syntactic sugar, you can also use the ``[]`` notation:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% for i in [1, 2, 3, 4, 5][start:length] %}
         {# ... #}

doc/filters/sort.rst

@@ -3,7 +3,7 @@
 
 The ``sort`` filter sorts an array:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% for user in users|sort %}
         ...

doc/filters/spaceless.rst

@@ -8,7 +8,7 @@
 Use the ``spaceless`` filter to remove whitespace *between HTML tags*, not
 whitespace within HTML tags or whitespace in plain text:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{
         "<div>
@@ -21,7 +21,7 @@ whitespace within HTML tags or whitespace in plain text:
 You can combine ``spaceless`` with the ``apply`` tag to apply the transformation
 on large amounts of HTML:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% apply spaceless %}
         <div>

doc/filters/split.rst

@@ -7,7 +7,7 @@
 The ``split`` filter splits a string by the given delimiter and returns a list
 of strings:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% set foo = "one,two,three"|split(',') %}
     {# foo contains ['one', 'two', 'three'] #}
@@ -22,7 +22,7 @@ You can also pass a ``limit`` argument:
 
 * If ``limit`` is zero, then this is treated as 1.
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% set foo = "one,two,three,four,five"|split(',', 3) %}
     {# foo contains ['one', 'two', 'three,four,five'] #}
@@ -30,7 +30,7 @@ You can also pass a ``limit`` argument:
 If the ``delimiter`` is an empty string, then value will be split by equal
 chunks. Length is set by the ``limit`` argument (one character by default).
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% set foo = "123"|split('') %}
     {# foo contains ['1', '2', '3'] #}

doc/filters/striptags.rst

@@ -4,13 +4,13 @@
 The ``striptags`` filter strips SGML/XML tags and replace adjacent whitespace
 by one space:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ some_html|striptags }}
 
 You can also provide tags which should not be stripped:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ some_html|striptags('<br><p>') }}
 

doc/filters/title.rst

@@ -4,7 +4,7 @@
 The ``title`` filter returns a titlecased version of the value. Words will
 start with uppercase letters, all remaining characters are lowercase:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ 'my first car'|title }}
 

doc/filters/trim.rst

@@ -10,7 +10,7 @@
 The ``trim`` filter strips whitespace (or other characters) from the beginning
 and end of a string:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ '  I like Twig.  '|trim }}
 

doc/filters/upper.rst

@@ -3,7 +3,7 @@
 
 The ``upper`` filter converts a value to uppercase:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ 'welcome'|upper }}
 

doc/filters/url_encode.rst

@@ -11,7 +11,7 @@
 The ``url_encode`` filter percent encodes a given string as URL segment
 or an array as query string:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ "path-seg*ment"|url_encode }}
     {# outputs "path-seg%2Ament" #}

doc/functions/attribute.rst

@@ -7,7 +7,7 @@
 The ``attribute`` function can be used to access a "dynamic" attribute of a
 variable:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ attribute(object, method) }}
     {{ attribute(object, method, arguments) }}
@@ -16,7 +16,7 @@ variable:
 In addition, the ``defined`` test can check for the existence of a dynamic
 attribute:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ attribute(object, method) is defined ? 'Method exists' : 'Method does not exist' }}
 

doc/functions/block.rst

@@ -10,7 +10,7 @@
 When a template uses inheritance and if you want to print a block multiple
 times, use the ``block`` function:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     <title>{% block title %}{% endblock %}</title>
 
@@ -21,14 +21,14 @@ times, use the ``block`` function:
 The ``block`` function can also be used to display one block from another
 template:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ block("title", "common_blocks.twig") }}
 
 Use the ``defined`` test to check if a block exists in the context of the
 current template:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% if block("footer") is defined %}
         ...

doc/functions/constant.rst

@@ -9,20 +9,20 @@
 
 ``constant`` returns the constant value for a given string:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ some_date|date(constant('DATE_W3C')) }}
     {{ constant('Namespace\\Classname::CONSTANT_NAME') }}
 
 As of 1.12.1 you can read constants from object instances as well:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ constant('RSS', date) }}
 
 Use the ``defined`` test to check if a constant is defined:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% if constant('SOME_CONST') is defined %}
         ...

doc/functions/cycle.rst

@@ -3,7 +3,7 @@
 
 The ``cycle`` function cycles on an array of values:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% set start_year = date() | date('Y') %}
     {% set end_year = start_year + 5 %}
@@ -14,7 +14,7 @@ The ``cycle`` function cycles on an array of values:
 
 The array can contain any number of values:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% set fruits = ['apple', 'orange', 'citrus'] %}
 

doc/functions/date.rst

@@ -9,7 +9,7 @@
 
 Converts an argument to a date to allow date comparison:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% if date(user.created_at) < date('-2days') %}
         {# do something #}
@@ -19,7 +19,7 @@ The argument must be in one of PHP’s supported `date and time formats`_.
 
 You can pass a timezone as the second argument:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% if date(user.created_at) < date('-2days', 'Europe/Paris') %}
         {# do something #}
@@ -27,7 +27,7 @@ You can pass a timezone as the second argument:
 
 If no argument is passed, the function returns the current date:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% if date(user.created_at) < date() %}
         {# always! #}

doc/functions/dump.rst

@@ -8,7 +8,7 @@ The ``dump`` function dumps information about a template variable. This is
 mostly useful to debug a template that does not behave as expected by
 introspecting its variables:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ dump(user) }}
 
@@ -31,7 +31,7 @@ introspecting its variables:
 In an HTML context, wrap the output with a ``pre`` tag to make it easier to
 read:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     <pre>
         {{ dump(user) }}
@@ -45,14 +45,14 @@ read:
 
 You can debug several variables by passing them as additional arguments:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ dump(user, categories) }}
 
 If you don't pass any value, all variables from the current context are
 dumped:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ dump() }}
 

doc/functions/include.rst

@@ -6,7 +6,7 @@
 
 The ``include`` function returns the rendered content of a template:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ include('template.html') }}
     {{ include(some_var) }}
@@ -19,7 +19,7 @@ paths defined by it.
 The context is passed by default to the template but you can also pass
 additional variables:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {# template.html will have access to the variables from the current context and the additional ones provided #}
     {{ include('template.html', {foo: 'bar'}) }}
@@ -27,12 +27,12 @@ additional variables:
 You can disable access to the context by setting ``with_context`` to
 ``false``:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {# only the foo variable will be accessible #}
     {{ include('template.html', {foo: 'bar'}, with_context = false) }}
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {# no variables will be accessible #}
     {{ include('template.html', with_context = false) }}
@@ -53,14 +53,14 @@ And if the expression evaluates to a ``\Twig\Template`` or a
 When you set the ``ignore_missing`` flag, Twig will return an empty string if
 the template does not exist:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ include('sidebar.html', ignore_missing = true) }}
 
 You can also provide a list of templates that are checked for existence before
 inclusion. The first template that exists will be rendered:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ include(['page_detailed.html', 'page.html']) }}
 
@@ -70,7 +70,7 @@ of the templates exist, otherwise it will throw an exception.
 When including a template created by an end user, you should consider
 sandboxing it:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ include('page.html', sandboxed = true) }}
 

doc/functions/max.rst

@@ -6,14 +6,14 @@
 
 ``max`` returns the biggest value of a sequence or a set of values:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ max(1, 3, 2) }}
     {{ max([1, 3, 2]) }}
 
 When called with a mapping, max ignores keys and only compares values:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ max({2: "e", 1: "a", 3: "b", 5: "d", 4: "c"}) }}
     {# returns "e" #}

doc/functions/min.rst

@@ -6,14 +6,14 @@
 
 ``min`` returns the lowest value of a sequence or a set of values:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ min(1, 3, 2) }}
     {{ min([1, 3, 2]) }}
 
 When called with a mapping, min ignores keys and only compares values:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ min({2: "e", 3: "a", 1: "b", 5: "d", 4: "c"}) }}
     {# returns "a" #}

doc/functions/parent.rst

@@ -4,7 +4,7 @@
 When a template uses inheritance, it's possible to render the contents of the
 parent block when overriding a block by using the ``parent`` function:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% extends "base.html" %}
 

doc/functions/random.rst

@@ -19,7 +19,7 @@ parameter type:
 * a random integer between the integer parameter (when negative) and 0 (inclusive).
 * a random integer between the first integer and the second integer parameter (inclusive).
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ random(['apple', 'orange', 'citrus']) }} {# example output: orange #}
     {{ random('ABC') }}                         {# example output: C #}

doc/functions/range.rst

@@ -3,7 +3,7 @@
 
 Returns a list containing an arithmetic progression of integers:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% for i in range(0, 3) %}
         {{ i }},
@@ -14,7 +14,7 @@ Returns a list containing an arithmetic progression of integers:
 When step is given (as the third parameter), it specifies the increment (or
 decrement for negative values):
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% for i in range(0, 6, 2) %}
         {{ i }},
@@ -27,7 +27,7 @@ decrement for negative values):
     Note that if the start is greater than the end, ``range`` assumes a step of
     ``-1``:
 
-    .. code-block:: jinja
+    .. code-block:: twig
 
         {% for i in range(3, 0) %}
             {{ i }},
@@ -38,7 +38,7 @@ decrement for negative values):
 The Twig built-in ``..`` operator is just syntactic sugar for the ``range``
 function (with a step of ``1``, or ``-1`` if the start is greater than the end):
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% for i in 0..3 %}
         {{ i }},

doc/functions/source.rst

@@ -9,7 +9,7 @@
 
 The ``source`` function returns the content of a template without rendering it:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ source('template.html') }}
     {{ source(some_var) }}
@@ -17,7 +17,7 @@ The ``source`` function returns the content of a template without rendering it:
 When you set the ``ignore_missing`` flag, Twig will return an empty string if
 the template does not exist:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ source('template.html', ignore_missing = true) }}
 

doc/functions/template_from_string.rst

@@ -9,7 +9,7 @@
 
 The ``template_from_string`` function loads a template from a string:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ include(template_from_string("Hello {{ name }}")) }}
     {{ include(template_from_string(page.template)) }}
@@ -17,7 +17,7 @@ The ``template_from_string`` function loads a template from a string:
 To ease debugging, you can also give the template a name that will be part of
 any related error message:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ include(template_from_string(page.template, "template for page " ~ page.name)) }}
 

doc/recipes.rst

@@ -67,7 +67,7 @@ and sometimes decorated with a layout. As Twig layout template names can be
 any valid expression, you can pass a variable that evaluates to ``true`` when
 the request is made via Ajax and choose the layout accordingly:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% extends request.ajax ? "base_ajax.html" : "base.html" %}
 
@@ -81,7 +81,7 @@ Making an Include dynamic
 When including a template, its name does not need to be a string. For
 instance, the name can depend on the value of a variable:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% include var ~ '_foo.html' %}
 
@@ -91,7 +91,7 @@ rendered.
 As a matter of fact, the template name can be any valid expression, such as
 the following:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% include var|default('index') ~ '_foo.html' %}
 
@@ -114,7 +114,7 @@ Let's say that your templates are loaded from both ``.../templates/mysite``
 and ``.../templates/default`` in this order. The ``page.twig`` template,
 stored in ``.../templates/default`` reads as follows:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {# page.twig #}
     {% extends "layout.twig" %}
@@ -126,7 +126,7 @@ You can replace this template by putting a file with the same name in
 ``.../templates/mysite``. And if you want to extend the original template, you
 might be tempted to write the following:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {# page.twig in .../templates/mysite #}
     {% extends "page.twig" %} {# from .../templates/default #}
@@ -142,7 +142,7 @@ time you will use the "normal" paths, but in the special case of wanting to
 extend a template with an overriding version of itself we can reference its
 parent's full, unambiguous template path in the extends tag:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {# page.twig in .../templates/mysite #}
     {% extends "default/page.twig" %} {# from .../templates #}
@@ -242,7 +242,7 @@ instance, if you have the following template data::
 
 And the following template to display all messages in all topics:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% for topic, messages in topics %}
         * {{ loop.index }}: {{ topic }}
@@ -515,7 +515,7 @@ From a template, you can easily load a template stored in a string via the
 ``template_from_string`` function (available as of Twig 1.11 via the
 ``\Twig\Extension\StringLoaderExtension`` extension):
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ include(template_from_string("Hello {{ name }}")) }}
 

doc/tags/apply.rst

@@ -6,7 +6,7 @@
 
 The ``apply`` tag allows you to apply Twig filters on a block of template data:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% apply upper %}
         This text becomes uppercase
@@ -14,7 +14,7 @@ The ``apply`` tag allows you to apply Twig filters on a block of template data:
 
 You can also chain filters and pass arguments to them:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% apply lower|escape('html') %}
         <strong>SOME TEXT</strong>

doc/tags/autoescape.rst

@@ -4,7 +4,7 @@
 Whether automatic escaping is enabled or not, you can mark a section of a
 template to be escaped or not by using the ``autoescape`` tag:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% autoescape %}
         Everything will be automatically escaped in this block
@@ -29,7 +29,7 @@ template to be escaped or not by using the ``autoescape`` tag:
 
     Before Twig 1.8, the syntax was different:
 
-    .. code-block:: jinja
+    .. code-block:: twig
 
         {% autoescape true %}
             Everything will be automatically escaped in this block
@@ -49,7 +49,7 @@ When automatic escaping is enabled everything is escaped by default except for
 values explicitly marked as safe. Those can be marked in the template by using
 the :doc:`raw<../filters/raw>` filter:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% autoescape %}
         {{ safe_value|raw }}
@@ -67,7 +67,7 @@ Functions returning template data (like :doc:`macros<macro>` and
 
     Twig does not escape static expressions:
 
-    .. code-block:: jinja
+    .. code-block:: twig
 
         {% set hello = "<strong>Hello</strong>" %}
         {{ hello }}

doc/tags/deprecated.rst

@@ -7,7 +7,7 @@
 Twig generates a deprecation notice (via a call to the ``trigger_error()``
 PHP function) where the ``deprecated`` tag is used in a template:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {# base.twig #}
     {% deprecated 'The "base.twig" template is deprecated, use "layout.twig" instead.' %}
@@ -15,7 +15,7 @@ PHP function) where the ``deprecated`` tag is used in a template:
 
 Also you can deprecate a block in the following way:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% block hey %}
         {% deprecated 'The "hey" block is deprecated, use "greet" instead.' %}

doc/tags/do.rst

@@ -7,6 +7,6 @@
 The ``do`` tag works exactly like the regular variable expression (``{{ ...
 }}``) just that it doesn't print anything:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% do 1 + 2 %}

doc/tags/embed.rst

@@ -12,7 +12,7 @@ included template, like when extending a template.
 
 Think of an embedded template as a "micro layout skeleton".
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% embed "teasers_skeleton.twig" %}
         {# These blocks are defined in "teasers_skeleton.twig" #}
@@ -116,7 +116,7 @@ as necessary:
 
 Page template ``foo.twig``:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% extends "layout_skeleton.twig" %}
 
@@ -134,7 +134,7 @@ Page template ``foo.twig``:
 
 And here is the code for ``vertical_boxes_skeleton.twig``:
 
-.. code-block:: html+jinja
+.. code-block:: html+twig
 
     <div class="top_box">
         {% block top %}
@@ -153,7 +153,7 @@ out the HTML markup for the boxes.
 
 The ``embed`` tag takes the exact same arguments as the ``include`` tag:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% embed "base" with {'foo': 'bar'} %}
         ...

doc/tags/extends.rst

@@ -12,7 +12,7 @@ The ``extends`` tag can be used to extend a template from another one.
 Let's define a base template, ``base.html``, which defines a simple HTML
 skeleton document:
 
-.. code-block:: html+jinja
+.. code-block:: html+twig
 
     <!DOCTYPE html>
     <html>
@@ -43,7 +43,7 @@ Child Template
 
 A child template might look like this:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% extends "base.html" %}
 
@@ -79,7 +79,7 @@ know which one of the blocks' content to use.
 If you want to print a block multiple times you can however use the
 ``block`` function:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     <title>{% block title %}{% endblock %}</title>
     <h1>{{ block('title') }}</h1>
@@ -92,7 +92,7 @@ It's possible to render the contents of the parent block by using the
 :doc:`parent<../functions/parent>` function. This gives back the results of
 the parent block:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% block sidebar %}
         <h3>Table Of Contents</h3>
@@ -106,7 +106,7 @@ Named Block End-Tags
 Twig allows you to put the name of the block after the end tag for better
 readability:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% block sidebar %}
         {% block inner_sidebar %}
@@ -122,7 +122,7 @@ Block Nesting and Scope
 Blocks can be nested for more complex layouts. Per default, blocks have access
 to variables from outer scopes:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% for item in seq %}
         <li>{% block loop_item %}{{ item }}{% endblock %}</li>
@@ -134,13 +134,13 @@ Block Shortcuts
 For blocks with little content, it's possible to use a shortcut syntax. The
 following constructs do the same thing:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% block title %}
         {{ page_title|title }}
     {% endblock %}
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% block title page_title|title %}
 
@@ -149,7 +149,7 @@ Dynamic Inheritance
 
 Twig supports dynamic inheritance by using a variable as the base template:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% extends some_var %}
 
@@ -172,7 +172,7 @@ instance, Twig will use it as the parent template::
 You can also provide a list of templates that are checked for existence. The
 first template that exists will be used as a parent:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% extends ['layout.html', 'base_layout.html'] %}
 
@@ -182,7 +182,7 @@ Conditional Inheritance
 As the template name for the parent can be any valid Twig expression, it's
 possible to make the inheritance mechanism conditional:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% extends standalone ? "minimum.html" : "base.html" %}
 
@@ -199,7 +199,7 @@ but it does not interfere in any way with the logic around it.
 Let's take the following example to illustrate how a block works and more
 importantly, how it does not work:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {# base.twig #}
 
@@ -214,7 +214,7 @@ If you render this template, the result would be exactly the same with or
 without the ``block`` tag. The ``block`` inside the ``for`` loop is just a way
 to make it overridable by a child template:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {# child.twig #}
 
@@ -231,7 +231,7 @@ Now, when rendering the child template, the loop is going to use the block
 defined in the child template instead of the one defined in the base one; the
 executed template is then equivalent to the following one:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% for post in posts %}
         <article>
@@ -242,7 +242,7 @@ executed template is then equivalent to the following one:
 
 Let's take another example: a block included within an ``if`` statement:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% if posts is empty %}
         {% block head %}
@@ -259,7 +259,7 @@ what will be rendered when the condition is ``true``.
 If you want the output to be displayed conditionally, use the following
 instead:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% block head %}
         {{ parent() }}

doc/tags/filter.rst

@@ -9,7 +9,7 @@
 Filter sections allow you to apply regular Twig filters on a block of template
 data. Just wrap the code in the special ``filter`` section:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% filter upper %}
         This text becomes uppercase
@@ -17,7 +17,7 @@ data. Just wrap the code in the special ``filter`` section:
 
 You can also chain filters and pass arguments to them:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% filter lower|escape('html') %}
         <strong>SOME TEXT</strong>

doc/tags/flush.rst

@@ -6,7 +6,7 @@
 
 The ``flush`` tag tells Twig to flush the output buffer:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% flush %}
 

doc/tags/for.rst

@@ -4,7 +4,7 @@
 Loop over each item in a sequence. For example, to display a list of users
 provided in a variable called ``users``:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     <h1>Members</h1>
     <ul>
@@ -21,7 +21,7 @@ provided in a variable called ``users``:
 If you do need to iterate over a sequence of numbers, you can use the ``..``
 operator:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% for i in 0..10 %}
         * {{ i }}
@@ -31,7 +31,7 @@ The above snippet of code would print all numbers from 0 to 10.
 
 It can be also useful with letters:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% for letter in 'a'..'z' %}
         * {{ letter }}
@@ -39,7 +39,7 @@ It can be also useful with letters:
 
 The ``..`` operator can take any expression at both sides:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% for letter in 'a'|upper..'z'|upper %}
         * {{ letter }}
@@ -68,7 +68,7 @@ Variable              Description
 ``loop.parent``       The parent context
 ===================== =============================================================
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% for user in users %}
         {{ loop.index }} - {{ user.username }}
@@ -91,7 +91,7 @@ Unlike in PHP, it's not possible to ``break`` or ``continue`` in a loop. You
 can however filter the sequence during iteration which allows you to skip
 items. The following example skips all the users which are not active:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     <ul>
         {% for user in users if user.active %}
@@ -117,7 +117,7 @@ The `else` Clause
 If no iteration took place because the sequence was empty, you can render a
 replacement block by using ``else``:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     <ul>
         {% for user in users %}
@@ -133,7 +133,7 @@ Iterating over Keys
 By default, a loop iterates over the values of the sequence. You can iterate
 on keys by using the ``keys`` filter:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     <h1>Members</h1>
     <ul>
@@ -147,7 +147,7 @@ Iterating over Keys and Values
 
 You can also access both keys and values:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     <h1>Members</h1>
     <ul>
@@ -162,7 +162,7 @@ Iterating over a Subset
 You might want to iterate over a subset of values. This can be achieved using
 the :doc:`slice <../filters/slice>` filter:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     <h1>Top Ten Members</h1>
     <ul>

doc/tags/if.rst

@@ -6,7 +6,7 @@ The ``if`` statement in Twig is comparable with the if statements of PHP.
 In the simplest form you can use it to test if an expression evaluates to
 ``true``:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% if online == false %}
         <p>Our website is in maintenance mode. Please, come back later.</p>
@@ -14,7 +14,7 @@ In the simplest form you can use it to test if an expression evaluates to
 
 You can also test if an array is not empty:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% if users %}
         <ul>
@@ -31,7 +31,7 @@ You can also test if an array is not empty:
 
 You can also use ``not`` to check for values that evaluate to ``false``:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% if not user.subscribed %}
         <p>You are not subscribed to our mailing list.</p>
@@ -39,7 +39,7 @@ You can also use ``not`` to check for values that evaluate to ``false``:
 
 For multiple conditions, ``and`` and ``or`` can be used:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% if temperature > 18 and temperature < 27 %}
         <p>It's a nice day for a walk in the park.</p>
@@ -48,7 +48,7 @@ For multiple conditions, ``and`` and ``or`` can be used:
 For multiple branches ``elseif`` and ``else`` can be used like in PHP. You can
 use more complex ``expressions`` there too:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% if product.stock > 10 %}
        Available

doc/tags/import.rst

@@ -7,7 +7,7 @@ macros are defined in regular templates.
 Imagine having a generic helper template that define how to render forms via
 macros (called ``forms.html``):
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% macro input(name, value, type, size) %}
         <input type="{{ type|default('text') }}" name="{{ name }}" value="{{ value|e }}" size="{{ size|default(20) }}" />
@@ -24,7 +24,7 @@ the template.
 The easiest and most flexible is importing the whole module into a local
 variable:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% import 'forms.html' as forms %}
 
@@ -39,7 +39,7 @@ variable:
 Alternatively you can import names from the template into the current
 namespace:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% from 'forms.html' import input as input_field, textarea %}
 

doc/tags/include.rst

@@ -4,7 +4,7 @@
 The ``include`` statement includes a template and returns the rendered content
 of that file:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% include 'header.html' %}
         Body
@@ -23,7 +23,7 @@ of that file:
     * The rendered template can be more easily stored in a variable when using
       the ``include`` function:
 
-      .. code-block:: jinja
+      .. code-block:: twig
 
           {% set content %}{% include 'template.html' %}{% endset %}
 
@@ -41,7 +41,7 @@ paths defined by it.
 
 You can add additional variables by passing them after the ``with`` keyword:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {# template.html will have access to the variables from the current context and the additional ones provided #}
     {% include 'template.html' with {'foo': 'bar'} %}
@@ -51,12 +51,12 @@ You can add additional variables by passing them after the ``with`` keyword:
 
 You can disable access to the context by appending the ``only`` keyword:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {# only the foo variable will be accessible #}
     {% include 'template.html' with {'foo': 'bar'} only %}
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {# no variables will be accessible #}
     {% include 'template.html' only %}
@@ -69,7 +69,7 @@ You can disable access to the context by appending the ``only`` keyword:
 
 The template name can be any valid Twig expression:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% include some_var %}
     {% include ajax ? 'ajax.html' : 'not_ajax.html' %}
@@ -94,7 +94,7 @@ You can mark an include with ``ignore missing`` in which case Twig will ignore
 the statement if the template to be included does not exist. It has to be
 placed just after the template name. Here some valid examples:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% include 'sidebar.html' ignore missing %}
     {% include 'sidebar.html' ignore missing with {'foo': 'bar'} %}
@@ -106,7 +106,7 @@ placed just after the template name. Here some valid examples:
 You can also provide a list of templates that are checked for existence before
 inclusion. The first template that exists will be included:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% include ['page_detailed.html', 'page.html'] %}
 

doc/tags/macro.rst

@@ -12,7 +12,7 @@ yourself.
 
 Here is a small example of a macro that renders a form element:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% macro input(name, value, type = "text", size = 20) %}
         <input type="{{ type }}" name="{{ name }}" value="{{ value|e }}" size="{{ size }}" />
@@ -26,7 +26,7 @@ Each argument can have a default value (here ``text`` is the default value for
     Before Twig 1.12, defining default argument values was done via the
     ``default`` filter in the macro body:
 
-    .. code-block:: jinja
+    .. code-block:: twig
 
         {% macro input(name, value, type, size) %}
             <input type="{{ type|default('text') }}" name="{{ name }}" value="{{ value|e }}" size="{{ size|default(20) }}" />
@@ -54,7 +54,7 @@ Macros can be defined in any template, and need to be "imported" before being
 used (see the documentation for the :doc:`import<../tags/import>` tag for more
 information):
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% import "forms.html" as forms %}
 
@@ -64,7 +64,7 @@ the ``forms`` local variable.
 
 The macro can then be called at will in the current template:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     <p>{{ forms.input('username') }}</p>
     <p>{{ forms.input('password', null, 'password') }}</p>
@@ -72,7 +72,7 @@ The macro can then be called at will in the current template:
 If macros are defined and used in the same template, you can use the
 special ``_self`` variable to import them:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% import _self as forms %}
 
@@ -88,7 +88,7 @@ special ``_self`` variable to import them:
 When you want to use a macro in another macro from the same file, you need to
 import it locally:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% macro input(name, value, type, size) %}
         <input type="{{ type|default('text') }}" name="{{ name }}" value="{{ value|e }}" size="{{ size|default(20) }}" />
@@ -108,7 +108,7 @@ Named Macro End-Tags
 Twig allows you to put the name of the macro after the end tag for better
 readability:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% macro input() %}
         ...

doc/tags/sandbox.rst

@@ -4,7 +4,7 @@
 The ``sandbox`` tag can be used to enable the sandboxing mode for an included
 template, when sandboxing is not enabled globally for the Twig environment:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% sandbox %}
         {% include 'user.html' %}
@@ -21,7 +21,7 @@ template, when sandboxing is not enabled globally for the Twig environment:
     cannot be used to sandbox a section of a template. The following example
     won't work:
 
-    .. code-block:: jinja
+    .. code-block:: twig
 
         {% sandbox %}
             {% for i in 1..2 %}

doc/tags/set.rst

@@ -6,14 +6,14 @@ the ``set`` tag and can have multiple targets.
 
 Here is how you can assign the ``bar`` value to the ``foo`` variable:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% set foo = 'bar' %}
 
 After the ``set`` call, the ``foo`` variable is available in the template like
 any other ones:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {# displays bar #}
     {{ foo }}
@@ -21,7 +21,7 @@ any other ones:
 The assigned value can be any valid :ref:`Twig expression
 <twig-expressions>`:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% set foo = [1, 2] %}
     {% set foo = {'foo': 'bar'} %}
@@ -29,7 +29,7 @@ The assigned value can be any valid :ref:`Twig expression
 
 Several variables can be assigned in one block:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% set foo, bar = 'foo', 'bar' %}
 
@@ -40,7 +40,7 @@ Several variables can be assigned in one block:
 
 The ``set`` tag can also be used to 'capture' chunks of text:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% set foo %}
         <div id="pagination">
@@ -58,7 +58,7 @@ The ``set`` tag can also be used to 'capture' chunks of text:
     Note that loops are scoped in Twig; therefore a variable declared inside a
     ``for`` loop is not accessible outside the loop itself:
 
-    .. code-block:: jinja
+    .. code-block:: twig
 
         {% for item in list %}
             {% set foo = item %}
@@ -68,7 +68,7 @@ The ``set`` tag can also be used to 'capture' chunks of text:
 
     If you want to access the variable, just declare it before the loop:
 
-    .. code-block:: jinja
+    .. code-block:: twig
 
         {% set foo = "" %}
         {% for item in list %}

doc/tags/spaceless.rst

@@ -8,7 +8,7 @@
 Use the ``spaceless`` tag to remove whitespace *between HTML tags*, not
 whitespace within HTML tags or whitespace in plain text:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% spaceless %}
         <div>

doc/tags/use.rst

@@ -15,7 +15,7 @@ limited to single inheritance; a template can only extend one other template.
 This limitation makes template inheritance simple to understand and easy to
 debug:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% extends "base.html" %}
 
@@ -25,7 +25,7 @@ debug:
 Horizontal reuse is a way to achieve the same goal as multiple inheritance,
 but without the associated complexity:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% extends "base.html" %}
 
@@ -37,7 +37,7 @@ but without the associated complexity:
 The ``use`` statement tells Twig to import the blocks defined in
 ``blocks.html`` into the current template (it's like macros, but for blocks):
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {# blocks.html #}
     
@@ -47,7 +47,7 @@ In this example, the ``use`` statement imports the ``sidebar`` block into the
 main template. The code is mostly equivalent to the following one (the
 imported blocks are not outputted automatically):
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% extends "base.html" %}
 
@@ -70,7 +70,7 @@ The main template can also override any imported block. If the template
 already defines the ``sidebar`` block, then the one defined in ``blocks.html``
 is ignored. To avoid name conflicts, you can rename imported blocks:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% extends "base.html" %}
 
@@ -87,7 +87,7 @@ The ``parent()`` function automatically determines the correct inheritance
 tree, so it can be used when overriding a block defined in an imported
 template:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% extends "base.html" %}
 
@@ -108,7 +108,7 @@ the ``blocks.html`` template.
     In Twig 1.2, renaming allows you to simulate inheritance by calling the
     "parent" block:
 
-    .. code-block:: jinja
+    .. code-block:: twig
 
         {% extends "base.html" %}
 

doc/tags/verbatim.rst

@@ -8,7 +8,7 @@ The ``verbatim`` tag marks sections as being raw text that should not be
 parsed. For example to put Twig syntax as example into a template you can use
 this snippet:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% verbatim %}
         <ul>

doc/tags/with.rst

@@ -7,7 +7,7 @@
 Use the ``with`` tag to create a new inner scope. Variables set within this
 scope are not visible outside of the scope:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% with %}
         {% set foo = 42 %}
@@ -19,7 +19,7 @@ Instead of defining variables at the beginning of the scope, you can pass a
 hash of variables you want to define in the ``with`` tag; the previous example
 is equivalent to the following one:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% with { foo: 42 } %}
         {{ foo }}           foo is 42 here
@@ -35,7 +35,7 @@ is equivalent to the following one:
 By default, the inner scope has access to the outer scope context; you can
 disable this behavior by appending the ``only`` keyword:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% set bar = 'bar' %}
     {% with { foo: 42 } only %}

doc/templates.rst

@@ -18,7 +18,7 @@ of the template.
 Below is a minimal template that illustrates a few basics. We will cover further
 details later on:
 
-.. code-block:: html+jinja
+.. code-block:: html+twig
 
     <!DOCTYPE html>
     <html>
@@ -76,7 +76,7 @@ You can use a dot (``.``) to access attributes of a variable (methods or
 properties of a PHP object, or items of a PHP array), or the so-called
 "subscript" syntax (``[]``):
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ foo.bar }}
     {{ foo['bar'] }}
@@ -85,7 +85,7 @@ When the attribute contains special characters (like ``-`` that would be
 interpreted as the minus operator), use the ``attribute`` function instead to
 access the variable attribute:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {# equivalent to the non-working foo.data-foo #}
     {{ attribute(foo, 'data-foo') }}
@@ -138,7 +138,7 @@ Setting Variables
 You can assign values to variables inside code blocks. Assignments use the
 :doc:`set<tags/set>` tag:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% set foo = 'foo' %}
     {% set foo = [1, 2] %}
@@ -155,21 +155,21 @@ applied to the next.
 The following example removes all HTML tags from the ``name`` and title-cases
 it:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ name|striptags|title }}
 
 Filters that accept arguments have parentheses around the arguments. This
 example will join a list by commas:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ list|join(', ') }}
 
 To apply a filter on a section of code, wrap it in the
 :doc:`apply<tags/apply>` tag:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% apply upper %}
         This text becomes uppercase
@@ -192,7 +192,7 @@ name followed by parentheses (``()``) and may have arguments.
 For instance, the ``range`` function returns a list containing an arithmetic
 progression of integers:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% for i in range(0, 3) %}
         {{ i }},
@@ -209,7 +209,7 @@ Named Arguments
 .. versionadded:: 1.12
     Support for named arguments was added in Twig 1.12.
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% for i in range(low=1, high=10, step=2) %}
         {{ i }},
@@ -218,7 +218,7 @@ Named Arguments
 Using named arguments makes your templates more explicit about the meaning of
 the values you pass as arguments:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ data|convert_encoding('UTF-8', 'iso-2022-jp') }}
 
@@ -229,7 +229,7 @@ the values you pass as arguments:
 Named arguments also allow you to skip some arguments for which you don't want
 to change the default value:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {# the first argument is the date format, which defaults to the global date format if null is passed #}
     {{ "now"|date(null, "Europe/Paris") }}
@@ -240,7 +240,7 @@ to change the default value:
 You can also use both positional and named arguments in one call, in which
 case positional arguments must always come before named arguments:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ "now"|date('d/m/Y H:i', timezone="Europe/Paris") }}
 
@@ -260,7 +260,7 @@ blocks.
 For example, to display a list of users provided in a variable called
 ``users``, use the :doc:`for<tags/for>` tag:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     <h1>Members</h1>
     <ul>
@@ -271,7 +271,7 @@ For example, to display a list of users provided in a variable called
 
 The :doc:`if<tags/if>` tag can be used to test an expression:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% if users|length > 0 %}
         <ul>
@@ -290,7 +290,7 @@ To comment-out part of a line in a template, use the comment syntax ``{# ...
 #}``. This is useful for debugging or to add information for other template
 designers or yourself:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {# note: disabled template because we no longer use this
         {% for user in users %}
@@ -304,7 +304,7 @@ Including other Templates
 The :doc:`include<functions/include>` function is useful to include a template
 and return the rendered content of that template into the current one:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ include('sidebar.html') }}
 
@@ -312,7 +312,7 @@ By default, included templates have access to the same context as the template
 which includes them. This means that any variable defined in the main template
 will be available in the included template too:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% for box in boxes %}
         {{ include('render_box.html') }}
@@ -324,7 +324,7 @@ The name of the template depends on the template loader. For instance, the
 ``\Twig\Loader\FilesystemLoader`` allows you to access other templates by giving the
 filename. You can access templates in subdirectories with a slash:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ include('sections/articles/sidebar.html') }}
 
@@ -344,7 +344,7 @@ starting with an example.
 Let's define a base template, ``base.html``, which defines a simple HTML
 skeleton document that you might use for a simple two-column page:
 
-.. code-block:: html+jinja
+.. code-block:: html+twig
 
     <!DOCTYPE html>
     <html>
@@ -371,7 +371,7 @@ template.
 
 A child template might look like this:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% extends "base.html" %}
 
@@ -401,7 +401,7 @@ It's possible to render the contents of the parent block by using the
 :doc:`parent<functions/parent>` function. This gives back the results of the
 parent block:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% block sidebar %}
         <h3>Table Of Contents</h3>
@@ -443,7 +443,7 @@ variables if needed. What to escape? Any variable you don't trust.
 Escaping works by piping the variable through the
 :doc:`escape<filters/escape>` or ``e`` filter:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ user.username|e }}
 
@@ -451,7 +451,7 @@ By default, the ``escape`` filter uses the ``html`` strategy, but depending on
 the escaping context, you might want to explicitly use any other available
 strategies:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ user.username|e('js') }}
     {{ user.username|e('css') }}
@@ -465,7 +465,7 @@ Whether automatic escaping is enabled or not, you can mark a section of a
 template to be escaped or not by using the :doc:`autoescape<tags/autoescape>`
 tag:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% autoescape %}
         Everything will be automatically escaped in this block (using the HTML strategy)
@@ -475,7 +475,7 @@ By default, auto-escaping uses the ``html`` escaping strategy. If you output
 variables in other contexts, you need to explicitly escape them with the
 appropriate escaping strategy:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% autoescape 'js' %}
         Everything will be automatically escaped in this block (using the JS strategy)
@@ -492,7 +492,7 @@ variable you have to use a trick.
 The easiest way is to output the variable delimiter (``{{``) by using a variable
 expression:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ '{{' }}
 
@@ -511,7 +511,7 @@ are useful to reuse often used HTML fragments to not repeat yourself.
 A macro is defined via the :doc:`macro<tags/macro>` tag. Here is a small example
 (subsequently called ``forms.html``) of a macro that renders a form element:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% macro input(name, value, type, size) %}
         <input type="{{ type|default('text') }}" name="{{ name }}" value="{{ value|e }}" size="{{ size|default(20) }}" />
@@ -520,7 +520,7 @@ A macro is defined via the :doc:`macro<tags/macro>` tag. Here is a small example
 Macros can be defined in any template, and need to be "imported" via the
 :doc:`import<tags/import>` tag before being used:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% import "forms.html" as forms %}
 
@@ -529,7 +529,7 @@ Macros can be defined in any template, and need to be "imported" via the
 Alternatively, you can import individual macro names from a template into the
 current namespace via the :doc:`from<tags/from>` tag and optionally alias them:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% from 'forms.html' import input as input_field %}
 
@@ -543,7 +543,7 @@ current namespace via the :doc:`from<tags/from>` tag and optionally alias them:
 A default value can also be defined for macro arguments when not provided in a
 macro call:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% macro input(name, value = "", type = "text", size = 20) %}
         <input type="{{ type }}" name="{{ name }}" value="{{ value|e }}" size="{{ size }}" />
@@ -569,7 +569,7 @@ even if you're not working with PHP you should feel comfortable with it.
     ``*``, ``/``, ``//``, ``%``, ``is`` (tests), ``**``, ``??``, ``|``
     (filters), ``[]``, and ``.``.
 
-    .. code-block:: jinja
+    .. code-block:: twig
 
         {% set greeting = 'Hello ' %}
         {% set name = 'Fabien' %}
@@ -607,7 +607,7 @@ exist:
 * ``{"foo": "bar"}``: Hashes are defined by a list of keys and values
   separated by a comma (``,``) and wrapped with curly braces (``{}``):
 
-  .. code-block:: jinja
+  .. code-block:: twig
 
     {# keys as string #}
     { 'foo': 'foo', 'bar': 'bar' }
@@ -630,7 +630,7 @@ exist:
 
 Arrays and hashes can be nested:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% set foo = [1, {"foo": "bar"}] %}
 
@@ -699,7 +699,7 @@ The following comparison operators are supported in any expression: ``==``,
 You can also check if a string ``starts with`` or ``ends with`` another
 string:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% if 'Fabien' starts with 'F' %}
     {% endif %}
@@ -712,7 +712,7 @@ string:
     For complex string comparisons, the ``matches`` operator allows you to use
     `regular expressions`_:
 
-    .. code-block:: jinja
+    .. code-block:: twig
 
         {% if phone matches '/^[\\d\\.]+$/' %}
         {% endif %}
@@ -724,7 +724,7 @@ The ``in`` operator performs containment test.
 
 It returns ``true`` if the left operand is contained in the right:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {# returns true #}
 
@@ -739,7 +739,7 @@ It returns ``true`` if the left operand is contained in the right:
 
 To perform a negative test, use the ``not in`` operator:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% if 1 not in [1, 2, 3] %}
 
@@ -752,7 +752,7 @@ Test Operator
 The ``is`` operator performs tests. Tests can be used to test a variable against
 a common expression. The right operand is name of the test:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {# find out if a variable is odd #}
 
@@ -760,13 +760,13 @@ a common expression. The right operand is name of the test:
 
 Tests can accept arguments too:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% if post.status is constant('Post::PUBLISHED') %}
 
 Tests can be negated by using the ``is not`` operator:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% if post.status is not constant('Post::PUBLISHED') %}
 
@@ -789,7 +789,7 @@ The following operators don't fit into any of the other categories:
 * ``..``: Creates a sequence based on the operand before and after the operator
   (this is just syntactic sugar for the :doc:`range<functions/range>` function):
 
-  .. code-block:: jinja
+  .. code-block:: twig
 
       {{ 1..5 }}
 
@@ -799,7 +799,7 @@ The following operators don't fit into any of the other categories:
   Note that you must use parentheses when combining it with the filter operator
   due to the :ref:`operator precedence rules <twig-expressions>`:
 
-  .. code-block:: jinja
+  .. code-block:: twig
 
       (1..5)|join(', ')
 
@@ -811,7 +811,7 @@ The following operators don't fit into any of the other categories:
 
 * ``?:``: The ternary operator:
 
-  .. code-block:: jinja
+  .. code-block:: twig
 
       {{ foo ? 'yes' : 'no' }}
 
@@ -821,7 +821,7 @@ The following operators don't fit into any of the other categories:
 
 * ``??``: The null-coalescing operator:
 
-  .. code-block:: jinja
+  .. code-block:: twig
 
       {# returns the value of foo if it is defined and not null, 'no' otherwise #}
       {{ foo ?? 'no' }}
@@ -836,7 +836,7 @@ String interpolation (``#{expression}``) allows any valid expression to appear
 within a *double-quoted string*. The result of evaluating that expression is
 inserted into the string:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ "foo #{bar} baz" }}
     {{ "foo #{1 + 2} baz" }}
@@ -872,7 +872,7 @@ The modifiers can be used on either side of the tags like in ``{%-`` or ``-%}``
 and they consume all whitespace for that side of the tag. It is possible to use
 the modifiers on one side of a tag or on both sides:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% set value = 'no spaces' %}
     {#- No leading/trailing whitespace -#}
@@ -898,7 +898,7 @@ the modifiers on one side of a tag or on both sides:
     In addition to the whitespace modifiers, Twig also has a ``spaceless`` filter
     that removes whitespace **between HTML tags**:
 
-    .. code-block:: jinja
+    .. code-block:: twig
 
         {% apply spaceless %}
             <div>

doc/tests/constant.rst

@@ -7,7 +7,7 @@
 ``constant`` checks if a variable has the exact same value as a constant. You
 can use either global constants or class constants:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% if post.status is constant('Post::PUBLISHED') %}
         the status attribute is exactly the same as Post::PUBLISHED
@@ -15,7 +15,7 @@ can use either global constants or class constants:
 
 You can test constants from object instances as well:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% if post.status is constant('PUBLISHED', post) %}
         the status attribute is exactly the same as Post::PUBLISHED

doc/tests/defined.rst

@@ -4,7 +4,7 @@
 ``defined`` checks if a variable is defined in the current context. This is very
 useful if you use the ``strict_variables`` option:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {# defined works with variable names #}
     {% if foo is defined %}
@@ -23,7 +23,7 @@ useful if you use the ``strict_variables`` option:
 When using the ``defined`` test on an expression that uses variables in some
 method calls, be sure that they are all defined first:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% if var is defined and foo.method(var) is defined %}
         ...

doc/tests/divisibleby.rst

@@ -7,7 +7,7 @@
 
 ``divisible by`` checks if a variable is divisible by a number:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% if loop.index is divisible by(3) %}
         ...

doc/tests/empty.rst

@@ -14,7 +14,7 @@ return value of the ``count()`` method.
 For objects that implement the ``__toString()`` magic method (and not ``Countable``),
 it will check if an empty string is returned.
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% if foo is empty %}
         ...

doc/tests/even.rst

@@ -3,7 +3,7 @@
 
 ``even`` returns ``true`` if the given number is even:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ var is even }}
 

doc/tests/iterable.rst

@@ -6,7 +6,7 @@
 
 ``iterable`` checks if a variable is an array or a traversable object:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {# evaluates to true if the foo variable is iterable #}
     {% if users is iterable %}

doc/tests/null.rst

@@ -3,7 +3,7 @@
 
 ``null`` returns ``true`` if the variable is ``null``:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ var is null }}
 

doc/tests/odd.rst

@@ -3,7 +3,7 @@
 
 ``odd`` returns ``true`` if the given number is odd:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {{ var is odd }}
 

doc/tests/sameas.rst

@@ -7,7 +7,7 @@
 ``same as`` checks if a variable is the same as another variable.
 This is the equivalent to ``===`` in PHP:
 
-.. code-block:: jinja
+.. code-block:: twig
 
     {% if foo.attribute is same as(false) %}
         the foo attribute really is the 'false' PHP value