mozilla-l10n / fxosl10ndashboard Goto Github PK

I am not sure yet how to measure that, but I talked with Delphine and she would like to be able to expose data there that is relevant for QA

It should be enough to put an empty index.php in there, and tell .gitignore to not ignore that file for /cache

to associate the name(s) of the people that are working on the project with each project

Some of the data sources are local (web dashboard / langchecker). Other resources are remote (l10n.mozilla.org, flod's server for marketplace). We may fetch more external ressources and remote API files in the future. It could be good to have some local caching of these files.

When the app is stable and we only have data updates, we will need to set up a corn job to git pull automatically.

current url:
http://l10n.mozilla-community.org/~pascalc/fxoslocales/

planned url:
http://l10n.mozilla-community.org/webdashboard/firefoxos/

As of January 1 2019, Mozilla requires that all GitHub projects include this CODE_OF_CONDUCT.md file in the project root. The file has two parts:

1. Required Text - All text under the headings Community Participation Guidelines and How to Report, are required, and should not be altered.
2. Optional Text - The Project Specific Etiquette heading provides a space to speak more specifically about ways people can work effectively and inclusively together. Some examples of those can be found on the Firefox Debugger project, and Common Voice. (The optional part is commented out in the raw template file, and will not be visible until you modify and uncomment that part.)

If you have any questions about this file, or Code of Conduct policies and procedures, please see Mozilla-GitHub-Standards or email [email protected].

(Message COC001)

move template in a separate file so as to separate logic from presentation + be able to switch template easily (for example to use a sandstoned template).

When you scroll all the way to the bottom, the table borders disappear. Tested on 22 and 25.

see title

the 'done' status is determined with the 'activate' method by using the status of the activate tag for production use in the lang file. We need to do the same for an in-progress status and decide on what criteria to use (probably just check that there are translated strings).

not exactly sure how we will assign the priorities , but we can experiment with various options.

this will allows us to group locales in more flexible ways. currently we have troubles communicating about the following groups of locales so maybe to start we might use:

p1 = locales we have shipped in previous releases
p2 = new locales that we have committe to for the next release
p3 = locales that has been requested by a partner
p4 = other locales that localization teams are working on in hopes of getting shipped

Work on making it use Sandstone style guides

replace column with columns for gaia l10n, gaia 1.1 and gaia 1.2 repos.

where we can't pull stuff automatically, or need to summarize it would be good to add comments for a locale.

this would be helpul in looking at the dashboard from lots of different perspectives.

Let's use Pike's data to determine priorities, that will be a first step for automation