docs(dependency-injection): tweak Dart wording

public/docs/ts/latest/guide/dependency-injection.jade

@@ -704,10 +704,13 @@ code-example(format, language="html").
     The injector resolves these tokens and injects the corresponding services into the matching factory function parameters.
 // #enddocregion providers-factory-4
 // #docregion providers-factory-5
+- var lang = current.path[1]
+- var anexportedvar = lang == 'dart' ? 'a constant' : 'an exported variable'
+- var variable = lang == 'dart' ? 'constant' : 'variable'
 :marked
-  Notice that we captured the factory provider in an exported variable, `heroServiceProvider`.
+  Notice that we captured the factory provider in #{anexportedvar}, `heroServiceProvider`.
   This extra step makes the factory provider reusable.
-  We can register our `HeroService` with this variable wherever we need it.
+  We can register our `HeroService` with this #{variable} wherever we need it.
 
   In our sample, we need it only in the `HeroesComponent`,
   where it replaces the previous `HeroService` registration in the metadata `providers` array.

public/docs/ts/latest/guide/template-syntax.jade

@@ -571,7 +571,7 @@ table
   If the name fails to match a property of a known directive or element, Angular reports an “unknown directive” error.
 
   ### Avoid side effects
-  As we've already discussed, evaluation of a template expression should have no visible side effects. The expression language itself does its part to keep us safe. We can’t assign a value to anything in a property binding expression nor use the increment and decorator operators.
+  As we've already discussed, evaluation of a template expression should have no visible side effects. The expression language itself does its part to keep us safe. We can’t assign a value to anything in a property binding expression nor use the increment and decrement operators.
 
   Of course, our expression might invoke a property or method that has side effects. Angular has no way of knowing that or stopping us.
 
@@ -940,16 +940,16 @@ code-example(format="", language="html").
 // #docregion ngModel-5
 .l-sub-section
   :marked
-    The `ngModel` input property sets the element's value property and the `ngModelChange` output property 
+    The `ngModel` input property sets the element's value property and the `ngModelChange` output property
     listens for changes to the element's value.
     The details are specific to each kind of element and therefore the `NgModel` directive only works for elements,
     such as the input text box, that are supported by a [ControlValueAccessor](../api/common/ControlValueAccessor-interface.html).
     We can't apply `[(ngModel)]` to our custom components until we write a suitable *value accessor*,
     a technique that is out of scope for this chapter.
-    
+
 :marked
   Separate `ngModel` bindings is an improvement. We can do better.
-  
+
   We shouldn't have to mention the data property twice. Angular should be able to capture the component’s data property and set it
   with a single declaration — which it can with the `[( )]` syntax:
 // #enddocregion ngModel-5
@@ -960,11 +960,11 @@ code-example(format="", language="html").
   :marked
     `[(ngModel)]` is a specific example of a more general pattern in which Angular "de-sugars" the `[(x)]` syntax
     into an `x` input property for property binding and an `xChange` output property for event binding.
-    Angular constructs the event property binding's template statement by appending `=$event` 
+    Angular constructs the event property binding's template statement by appending `=$event`
     to the literal string of the template expression.
   code-example(format="." ).
     [(x)]="hero.name" <==> [x]="hero.name" (xChange)="hero.name=$event"
-    
+
   :marked
     We can write a two-way binding directive of our own to exploit this behavior.