Bug 1443697 - Fix nits in Fluent for Firefox Developers. r=flod
authorZibi Braniecki <zbraniecki@mozilla.com>
Tue, 06 Mar 2018 17:48:17 -0800
changeset 461890 8f02fba87e70a1213a32d35d0937e90e96477506
parent 461889 5f8f9db9e66db97bd5250357ce33e7a507bdf613
child 461891 4d6f6524467a30ea8c3115e8941635dd4a7f2168
push id1683
push usersfraser@mozilla.com
push dateThu, 26 Apr 2018 16:43:40 +0000
treeherdermozilla-release@5af6cb21869d [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
reviewersflod
bugs1443697
milestone60.0a1
first release with
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
last release without
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
Bug 1443697 - Fix nits in Fluent for Firefox Developers. r=flod MozReview-Commit-ID: 4QSBa01XXp3
intl/l10n/docs/fluent_tutorial.rst
--- a/intl/l10n/docs/fluent_tutorial.rst
+++ b/intl/l10n/docs/fluent_tutorial.rst
@@ -180,17 +180,17 @@ to recognize that Fluent formalizes this
   localization output as `opaque`. That means that no concatenations, replacements
   or splitting should happen after the translation is completed to generate the
   desired output.
 
 In return, localizers enter the social contract by promising to provide an accurate
 and clean translation of the messages that match the request.
 
 In previous localization systems, developers were responsible for differentiating
-string variant based on a platform via pre-processing instructions, or
+string variants based on a platform via pre-processing instructions, or
 selecting which strings should be formatted using `PluralForms.jsm`.
 
 In Fluent, the developer is not to be bothered with inner logic and complexity that the
 localization will use to construct the response. Whether `declensions`__ or other
 variant selection techniques are used is up to a localizer and their particular translation.
 From the developer perspective, Fluent returns a final string to be presented to
 the user, with no l10n logic required in the running code.
 
@@ -234,17 +234,17 @@ The other change is that the developer c
   -brand-short-name = Firefox
   update-application-info =
       You are using { -brand-short-name } Version: { $version }.
       <span>Please, read the <a>privacy policy</a>.</span>
 
 
 Fluent will overlay the translation onto the source fragment preserving attributes like
 :code:`class` and :code:`href` from the source and adding translations for the elements
-inside. The end result will look like this:
+inside. The resulting localized content will look like this:
 
 .. code-block:: html
 
   <p data-l10n-id="update-application-info" data-l10n-args="{'version': '60.0'}">
     You are using Firefox Version: 60.0.
     <span class="bold">
       Please, read the <a href="http://www.mozilla.org/privacy">privacy policy</a>.
     </span>
@@ -269,21 +269,21 @@ External Arguments
 ------------------
 
 Notice in the previous example the attribute :code:`data-l10n-args`, which is
 a JSON object storing variables exposed by the developer to the localizer.
 
 This is the main channel for the developer to provide additional variables
 to be used in the localization.
 
-It is very rare that the arguments are needed for localizations which previously
-used DTD, because such variables will usually have to be computed from the runtime code,
-but it is worth understanding that when the :code:`l10n-args` are set in
-the runtime code, they are in fact encoded via JSON and stored together with
-:code:`l10n-id` as an attribute on the element.
+Arguments are rarely needed for situations where it’s currently possible to use
+DTD, since such variables would need to be computed from the code at runtime.
+It's worth noting that, when the :code:`l10n-args` are set in
+the runtime code, they are in fact encoded as JSON and stored together with
+:code:`l10n-id` as an attribute of the element.
 
 __ https://www.w3.org/TR/2011/WD-html5-20110525/text-level-semantics.html
 
 
 Runtime Localization
 ====================
 
 Fluent fully replaces the use of `StringBundle`_ in localization.
@@ -464,17 +464,17 @@ representation of the date in string:
 In most cases, that will be enough and the date would get formatted in the current
 Firefox as `February 28, 2018`.
 
 But if in some other locale the string would get too long, the localizer can fine
 tune the options as well:
 
 .. code-block:: properties
 
-  welcome-message = Początek Twojej sesji: { DATETIME($startDate, month="short") }
+  welcome-message = Początek Twojej sesji: { DATETIME($startDate, month: "short") }
 
 This will adjust the length of the month token in the message to short and get formatted
 in Polish as `28 lut 2018`.
 
 At the moment Fluent supports two formatters that match JS Intl API counterparts:
 
  * **NUMBER**: `Intl.NumberFormat`__
  * **DATETIME**: `Intl.DateTimeFormat`__
@@ -534,40 +534,40 @@ The above method creates a single locali
 In almost all scenarios that's sufficient.
 
 In rare edge cases where the developer needs to fetch additional resources, or
 the same resources in another language, it is possible to create additional
 contexts manually using `Localization` class:
 
 .. code-block:: javascript
 
-	const { Localization } =
-		ChromeUtils.import("resource://gre/modules/Localization.jsm", {});
-
-
-	const myL10n = new Localization([
-		"branding/brand.ftl",
-		"browser/preferences/preferences.ftl"
-	]);
-
-
-	let [isDefaultMsg, isNotDefaultMsg] =
-		myL10n.formatValues(["is-default", "is-not-default"]);
+  const { Localization } =
+    ChromeUtils.import("resource://gre/modules/Localization.jsm", {});
+  
+  
+  const myL10n = new Localization([
+    "branding/brand.ftl",
+    "browser/preferences/preferences.ftl"
+  ]);
+  
+  
+  let [isDefaultMsg, isNotDefaultMsg] =
+    myL10n.formatValues(["is-default", "is-not-default"]);
 
 
 .. admonition:: Example
 
   An example of a use case is the Preferences UI in Firefox which uses the
   main context to localize the UI but also to build a search index.
 
-  It is common to build such search index both in a current langauge and additionally
-  in English since a lot of documentation and online help exists in that language.
+  It is common to build such search index both in a current language and additionally
+  in English, since a lot of documentation and online help exist only in English.
 
-  A developer may create manually a new context with the same resources as the main one
-  uses, but hardcode it to `en-US` and then build the search index using both contexts.
+  A developer may create manually a new context with the same resources as the main one,
+  but hardcode it to `en-US` and then build the search index using both contexts.
 
 Designing Localizable APIs
 ==========================
 
 When designing localizable APIs, the most important rule is to resolve localization as
 late as possible. That means that instead of resolving strings somewhere deep in the
 codebase and then passing them on or even caching, it is highly recommended to pass
 around :code:`l10n-id` or :code:`[l10n-id, l10n-args]` pairs until the top-most code
@@ -587,20 +587,20 @@ the code sets the right :code:`l10n-id`/
 
 .. code-block:: javascript
   
   testedFunction();
   
   const l10nAttrs = document.l10n.getAttributes(element);
   
   deepEquals(l10nAttrs, {
-		id: "my-expected-id",
-		args: {
-			unreadCount: 5
-		}
+    id: "my-expected-id",
+    args: {
+      unreadCount: 5
+    }
   });
 
 If the code really has to test for particular values in the localized UI, it is
 always better to scan for a variable:
 
 .. code-block:: javascript
 
   testedFunction();