No place for translation contribution in the schema

[pmclanahan]

I'm not sure yet where this info should go, but I believe it would be beneficial to call out specifically translation contribution URLs and contacts. I was originally thinking maybe it belongs under the "participate" key, but now maybe a top level "localization" or "translation" key is called for.

[pmclanahan]

@peterbe @Osmose thoughts?

[Osmose]

I'm curious if @flodolo, @Pike, or @mathjazz are interested and what kind of info they'd want to put in a contribute.json file. Would it just be a URL to a single page, or maybe a map of locales to URLs for locale-specific landing pages?

[Pike]

Looping on more folks, @stasm and @zbraniecki have given some thought about json structures and l10n for web app manifests.

[flodolo]

In this case I don't think the issue is the JSON, but what kind of information we'd like to put in it (see current).

"Translation" would be probably easier to understand (localization and l10n are pretty much jargon.

Some useful info would include:

• mailing list for web parts
• https://l10n.mozilla.org/ as entry point. Once chosen a locale, you have plenty of links (including Contacts)

[peterbe]

@Pike (and all other l10n experts), If a potential contributor was to come to you in person and ask "How can I use my foreign language skills to help this web app/web site/code project?" How would you answer hem? ...in terms of links ideally specific to the specific project.

@flodolo mailing list and l10n.mozilla.org isn't specific to the project. The idea with contribute.json is that each project has its own.

What's Jeff's github username?

[mathjazz]

@gueroJeff

[stasm]

@Pike's referring to https://github.com/w3c/manifest/issues/211 which is more about the localizing the fields of the manifest than adding language-specific data to the manifest.

I think the fields of the participate key are relevant for localization in general and for every language team. Even if it feels a bit too complex to me, I think I'd go for a top-level translate key which mirrors the fileds of participate:

"translate": {
  "home": "https://l10n.myproject.com",
  "docs": "http://myproject.readthedocs.org/l10n",
  "mailing-list": "https://www.mozilla.org/about/forums/#dev-l10n",
  "irc": "irc://irc.mozilla.org/#l10n",
  "languages": {
    "en-US": "http://…",
    "pl": {
      "home": "http://aviary.pl",
      "irc": "irc://irc.mozilla.org/#aviarypl"
    }
  }
}

[Pike]

Oops, completely misunderstood the ask.

Not sure to which extent we can help here. I suspect that each project needs to create a page as an entry point, linking to whatever can help from there.

Adding an entry per language doesn't seem to fit the usecase of the inventory (that'd just blow up).

[mathjazz]

Or simply add "translate" key under "participate" with project-specific link to the l10n entry point as the value (either website, mailing list, email address, etc.).

[pmclanahan]

I like @stasm's structure, but also agree with @Pike that having info per locale seems excessive.

@mathjazz I like that as well, but if we move it under "participate" then it'd feel weird to have it nested in a similar structure. I'd be inclined to move the existing "participate" keys under "participate.code" and have along side that "participate.translate". But in the interest of backward compatibility, I'm pretty happy with just a new top-level "translate" key that is very similar in structure to the current "participate" one. e.g.:

{ 
   "translate": {
        "home": "https://l10n.mozilla.org/",
        "docs": "http://bedrock.readthedocs.org/en/latest/l10n.html",
        "mailing-list": "https://lists.mozilla.org/listinfo/dev-l10n-web",
        "irc": "irc://irc.mozilla.org/#l10n",
        "irc-contacts": [
            "flod",
            "pascalc"
        ]
    },
}

[MikkCZ]

@mathjazz pointed me to this issue. Few month ago I have started with an add-on for localizers to bring them deeper integration with Pontoon to help with the l10n process. Having l10n information in manifest.json would help me with discovering all the staging and testing domains. Having a link to Pontoon project (https://pontoon.mozilla.org/projects/test-pilot-website/ in https://testpilot.firefox.com/contribute.json for example) would help me pair the website with the correct projects in Pontoon, until this information is provided by Pontoon API. And after the API is in place, Pontoon can actually use contribute.json to update the information it shows to localizers.

I am not sure if a single link would be sufficient. At least for SUMO and MDN content is translated separately, so specifically in case of SUMO both https://pontoon.mozilla.org/projects/sumo/ and https://support.mozilla.org/localization would be relevant.

[peterbe]

@MikkCZ So what do you think about @pmclanahan 's pull request? Perhaps redirect comments to the specifics there. In particular your point you made about the fact that some websites have two translate projects.

[MikkCZ]

Sorry @peterbe for my late reply. I think home and docs should be arrays here. In case of SUMO or MDN the user interface and articles content are localized differently, so there can be multiple places to point both for translation interface or documentation. Also AMO localization is split into addons-server and addons-frontend.

Btw. I am not sure if home is the best descriptive field name here. It is not clear to me, where it should point - Pontoon or other translation interface, some get involved l10n page, project style guide, localizers forum, ... ?

[peterbe]

@MikkCZ Please move the discussion of implementation details into @pmclanahan 's PR. I don't know who has the last say but I think you need to push for a solution where it works to have 1 contribute.json but more than 1 l10n projects. Also, does JSONSchema allow for properties to be string OR array of strings?