Maintaining Fjord and Input

Onboarding a new developer

  1. Watch the “Input” product and “__Any__” component in Bugzilla in your Bugzilla Component Watching preferences
  2. Hop on the #input IRC channel on
  3. Create an IT bug for getting added to error email lists
  4. Ask an existing developer with an admin account on Input to create an admin account for you
  5. Get access to push changes to
  6. Update the wiki page
  7. Read the documentation:
    wiki page:
  8. Set up your development environment by reading through and doing all the things in the Getting started
  9. If you haven’t read through the Webdev Bootcamp, now is a good time
  10. Bask in the tranquil rhythmic sounds of the Fjord

Triaging bugs for contributors

Bugs designated for contributors fall into two groups:

  1. good first bugs
  2. good next bugs

Good first bugs should ideally touch one aspect of the code base, be self-contained, and not require a lot of knowledge about how the system works.

Good first bugs are denoted in Bugzilla with:

  • [good first bug] in the Whiteboard field
  • a mentor listed in the Mentors field
  • a comment explaining the problem and what needs to be done to fix it

Good next bugs are everything else and are denoted in Bugzilla with:

  • a mentor listed in the Mentors field
  • a comment explaining the problem and what needs to be done to fix it

It’s good to go through bugs once a month to see if any new bugs popped up that’d be good for contributors as well as for bugs that currently exist that probably should get closed out.

Comment template:

Marking this as a mentored bug. If you're interested in working on it,
please read through our "Join this project" guide [1], complete the
list of things you need to do before contributing and then add a comment
to this bug asking to have it assigned to you.



<required skills>

<explanation of how to implement>

<note any wry twists>


If you have any questions, please ask in the comments on this bug, on
the mailing list or in the #input IRC channel on

Once a week, go through any assigned mentored bugs and ping them to see how they’re coming along.

Adding support for a new product

To add support for a new product via product urls for the feedback form or the Feedback API, add a new entry to the Products table.

Adding a new locale

To add a new locale so that works and so that people can see the site in that language and submit feedback:

  1. In your local repository, run:

    $ ./ update_product_details
  2. Check lib/product_details_json/languages.json to see if the language is there.

    1. If not, you need to file a bug to get it added. See for example.

    Once the locale is listed in lib/product_details_json/languages.json, proceed.

  3. Update locale/ and check to see if the locale is listed there.

    1. If you don’t have a locale/ directory or don’t know how to update it, see Maintaining l10n.
    2. If the locale isn’t in the locale/ directory, ask Milos to add Input to the list of translated projects for that locale. See for better language because I only vaguely understand how the Verbatim side works.

    Once the locale is in git and locale/, proceed.

  4. Add the locale code to the PROD_LANGUAGES list in fjord/settings/

  5. Commit the changes to fjord/settings/ and product details stuff to git.

Making strings changes to feedback forms

Feedback forms must be fully translated in specific target locales before they can be pushed to production.

Process for making feedback form strings changes:

  1. create a new branch
  2. make the changes you need to make
  3. submit a pull request
  4. after the pull request is approved (r+), extract and merge strings from that branch
  5. send an email to the dev-l10n-web mailing list—see Extract/merge/sync strings with git for details

Now you have to wait until the target locales have fully translated the new strings.

Use the bin/ script to tell you whether things are good to go or not.

Once they’re good to go, you can land the changes in master and push to stage and production.

For the list of target locales per form, see Cheng, Matt or Will.

Dealing with errors in translated strings

When we deploy a new version of Fjord, it updates the .po files and picks up newly translated strings.

.po files that have errors will not get compiled to .mo files and thus won’t go to production and thus won’t cause fires.

Note that this doesn’t mean that this locale will have no translations—we’ll use the previously compiled .mo file.

If there is no .mo file, then the deployment will compile a .mo file even if there are errors with the figuring that a problematic .mo file is better than nothing and that this should be an exceedingly rare occurrence.

If .po files have errors, then those errors are noted in the postatus.txt files:

If there are errors in those files, we need to open up a bug in Mozilla Localizations -> locale code with the specifics.

Bug description template:

We found errors in the translated strings for Input (
The errors are as follows:

<paste errors here>

Until these errors are fixed, we can't deploy updates to the strings for this locale.

If you have any questions, let me know.