Badge localization

[brianloveswords]

From @thisandagain:

As an aside, would now be a good time to think about extending the badge schema? Two items that arose during my experiment were those of geolocation and language specification. For example:

{
    "name": "MOOC GdP : fondamentaux des projets",
    "description": "A démontré sa connaissance du cours “fondamentaux de la gestion de projet” du MOOC GdP. Voir gestiondeprojet.pm ou http://goo.gl/Hu3GA",
    "image": "https://badge.unow.fr/badges/badge_classique_S1.png",
    "criteria": "https://badge.unow.fr/badges/criteria/22/1b605d6937b8e527cff67d9eb0bd649d",
    "issuer": "https://badge.unow.fr/api/v1/organizations/1-unow-mooc-badges.json",
    "alignment": [],
    "tags": []
}

In this instance it would be great to append something like:

{
    "language": "fr-fr",
    "location": [someLat, someLong]
}

This would allow us to easily localize search, and also provide better recommendations for pathways based on user language and locale preferences.

/cc @christi3k

[brianloveswords]

The potential issue with this scheme is that it doesn't work for badges that might require multiple localizations while still being the exact same badge class.

[cmcavoy]

We need a way to link BadgeAssertions with a relationship. A single assertion can have multiple related assertions - maybe they're localized, maybe they're 'pie badges' maybe they're linked as a chain in a 'learning pathway'.

There's a bunch of use cases that seem to point to "badges need to relate to one another in a machine readable way". If we nail that, a bunch of pieces fall in line.

[cmcavoy]

FOAF is clunky - we just want simple triplets - "this link is the fr-fr version of this assertion".

[toolness]

The potential issue with this scheme is that it doesn't work for badges that might require multiple localizations while still being the exact same badge class.

Would it be completely bonkers to use the Accept-Language header to determine what language to provide the localized badge in? And perhaps append something like:

{
  "languages": ["fr-fr", "en"]
}

to let clients know what localizations are actually available?

[avisser]

On a different localization note, the fact that badge baking writes to a tEXt block (which is LATIN-1) as opposed to iTXt (UTF-8) seems an impediment.

[iamjessklein]

just wanted to chime in with a huge +1 for this general concept. For two reasons: 1. with location specific badges ( imagine SMS badging) it could be helpful to incorporate this information as useful data points - akin to evidence and 2. with the @toolness suggestion, (I believe) that it will help us to dive in to localizable versions of badges. and 3 (yeah I lied - 3!) with our interest in badgekit for cities - this feels like a no - brainer as learning, badge and skill acquisition will be happening on a hyper-local level.

[carlacasilli]

:+1:

[colinfrei]

On a different localization note, the fact that badge baking writes to a tEXt block (which is LATIN-1) as opposed to iTXt (UTF-8) seems an impediment.

If that's the case that's potentially a pretty big issue which should be solved sooner rather than later.

[brianloveswords]

Ah, forgot to update this – we are now baking into iTXt. We patched that with mozilla/openbadges-bakery@3b94cb2a8bc41462a9fa7b120731f68ada24e24f and changed the baking specification here: https://github.com/mozilla/openbadges-specification/blob/master/Badge-Baking/latest.md

[iamjessklein]

:octocat: :+1: :tada:

[timothyfcook]

Both of these discussions have been addressed in actionable tickets within the Spec repo and have been added to the 2.0 spec! Moving to the archive.