1296039 - Create a template repository in GitHub for GoFaster system add-ons

Status: RESOLVED FIXED

(Developer Documentation Graveyard :: Add-ons, defect)

Description

[Cory Price [:ckprice] (bugmail disabled, NI me!)]

It would be helpful if developers had a template GitHub repository to reference as they are building a system add-ons.

This was discussed in our 20160816 meeting[0], some of the items mentioned were:

- examples of the main methods.
- examples of localization scripts.
- references in the add-on to important areas of process documents[1].


[0] https://pad.mocotoolsprod.net/gofaster_20160816
[1] https://wiki.mozilla.org/Firefox/Go_Faster/Process

Comment 1

[Eric Shepherd [:sheppy]]

Hi Cory. This sounds awesome, and I sure look forward to seeing it. That said, any content needed for MDN will need to be produced by your team or by others you find to do the work, because unfortunately the MDN content team has had to deprioritize work on Firefox internals documentation such as this, due to the huge amount of content that needs to be done on the web development side and the relatively small supply of writer-hours. Because of that, we encourage teams to maintain their own Firefox internals/test/development content.


See our contributor guide here if you're interested in helping to update that documentation: https://developer.mozilla.org/en-US/docs/MDN/Getting_started

We can certainly advise and review to ensure the content is awesome once it's done, though.

Comment 2

[Mark Banner (:standard8)]

I've started creating a small repo here:

https://github.com/mozilla/example-addon-repo

There's not much in it at the moment, just a very basic jpm based add-on, and some lint tests. However, I'm hoping to get it fleshed out more over the next week or so.

Note: a lot of the structure is likely to change significantly at this time.

Comment 3

[Francesco Lodolo [:flod]]

As l10n we're definitely interested in setting guidelines for system add-ons.

If a project can't live within the constraints of the current release cycle, i.e. strings land in mozilla-central and ride the trains, strings should not live in mozilla-* repositories and be exposed to localization tools directly. 

Our suggestion is to use a separate ad-hoc GitHub repository to store strings for each system add-on, and to create it in the mozilla-l10n organization. Some pros of this solution:
* Development can go ahead without exposing strings to localization Tools. To do that, developers will need to update en-US in the strings-only repository.
* Localizers would have access directly to the repository, if they don't want to use Pontoon.
* Pulling strings in the code repository is relatively simple.

These would be the steps to setup a new project:
1. Create the repository in mozilla-l10n. Folder structure should follow Pontoon's guidelines: https://docs.google.com/document/d/1ZBK19Qg_bRr9Mcg-jjSIANUL9cwuwoqYTePlEcZ4cO8/edit?usp=sharing
2. Give commit access to developers.
3. Define the list of supported locales, deadline.
4. Add en-US strings.
5. Set up the project in Pontoon.

Points 1, 2, and 5 would be on l10n-drivers.

What needs to be added to the template:
1. Scripting to retrieve strings from an external repository (Hello is already doing it).
2. Scripting to ship only locales that are completely localized, or merge missing strings from en-US. We currently don't have that anywhere.

More details on the discussion on l10n
https://docs.google.com/document/d/1ZBK19Qg_bRr9Mcg-jjSIANUL9cwuwoqYTePlEcZ4cO8/edit?usp=sharing

Comment 4

[Mark Banner (:standard8)]

I've now started on transitioning to WebExtensions, there's some issues with the L10n formats not being the same as FF, but its generally works well, and its easy to do proper unit tests.

I've started a discussion about l10n on the go faster list, though that may move to a different place.

The branch I'm working on is here:

https://github.com/mozilla/example-addon-repo/compare/webextensions

Comment 5

[Mark Banner (:standard8)]

The webextensions branch has now landed on master. I've updated the issues in github with the currently known ones.

Comment 6

[Mark Banner (:standard8)]

I've just updated the repo, got the tests passing again, and switched to being a legacy add-on. There's still a few things that could be fixed, but we'll track those on issues in the repo.

Hence calling this bug "fixed".