Open Bug 1410849 Opened 7 years ago Updated 7 years ago

Fall back to the id of the message if it's missing from all locales

Categories

(L20n :: JS Library, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

People

(Reporter: stas, Unassigned)

References

(Blocks 1 open bug)

Details

Bug 1402069 comment 45:

> (…) long time ago we talked about
> returning l10nId as the last resort fallback for missing entries.
> Now I see that `Localization.formatValue` returns `undefined` instead.

valueFromContext and messageFromContext return the id if the message is missing. The code in keysFromContext, however, doesn't put that id into the array of translations to be returned because the missing message also produced an error. The translations array is sparse and has undefineds in places corresponding to messages missing in the contexts seen so far. When we fall back to the next context, we only fill in the undefined. However, there's no logic that ensure the undefined are taken care of if we run out of context to fall back to.
I've been meaning to refactor all of Localization as described in bug 1410857. The refactor would also fix this bug. My plan was to wait with the refactor until we have a way to measure the performance of the current solution.

I see three ways forward depending of how serious this bug is:

  1. fix the current implementation now (and add tests which will make the refactor easier),
  2. accept "undefined" as a known issue and wait for the refactor,
  3. refactor now.

Zibi, do you have a preference? I would recommend #1 but it's the most work-intensive and I'd like to make sure we make time for it in the schedule.
Flags: needinfo?(gandalf)
I'm ok with (2) for soft-launch and (3) as a blocker for any milestone past first-migration.
Flags: needinfo?(gandalf)
(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #2)
> I'm ok with (2) for soft-launch and (3) as a blocker for any milestone past
> first-migration.

This sentence doesn't define your preference for the first-migration milestone :)

Is there a tracking bug for the open-migration milestone? I'd like to set bug 1410857 as a blocker.
> This sentence doesn't define your preference for the first-migration milestone :)

I'm ok with (2) for first-migration as well.

> Is there a tracking bug for the open-migration milestone? I'd like to set bug 1410857 as a blocker.

Not yet, we're negotiating updates to the milestones past M2, so I'm waiting for that to happen before I fill trackers. For now, everything that doesn't have a specific milestones is set to block bug 1365426. Once I add a specific milestone tracking bug, I move items that block that milestone to block that bug.
You need to log in before you can comment on or make changes to this bug.