While working on mock_l20n in https://bugzil.la/1208369 I remembered this thread. Zibi, any thoughts on the future of l10nId?
On Wed, Aug 12, 2015 at 4:54 PM, Staś Małolepszy <[email protected]> wrote: > I see the value of the helper, especially right now, but I generally have > doubts about this polymorphism. I base that on a set of the following 4 > principles: > > - avoid direct manipulation of textContent (because it requires manual > retranslations), > - avoid direct manipulation of innerHTML (because it's not safe), > - give more control to the localizer (don't bypass the localization layer > and insert the text yourself), and > - redundancy is good for localization because it gives localizers even > more control. > > With these in mind, I think that many of the use-cases of the l10n-id > object could be serviced simpler by having two entities: > > <songtitle "{{ $songtitle }}"> > <songtitleUnknown "Unknown sing"> > > or, if more text is needed: > > <deviceConnected "You've connected to {{ $deviceName }}"> > <deviceConnectedUnknown "You've connected to an unknown device."> > > Would that help us achieve the same goal? > > -stas > > On Sun, Aug 2, 2015 at 4:47 AM, Zibi Braniecki < > [email protected]> wrote: > >> As I work with Gaia apps to migrate more of them to L20n API I noticed >> that a lot of apps need to behave in a polymorphic way when it comes to >> translation. >> >> Instead of clear element is localized by an entity with ID X, we have a >> scenario where something may receive an ID or a raw string or maybe an >> ID/Args combo. >> >> The two common scenario is HTML element translation: >> >> var songName = data.name; >> >> if (songName) { >> nameElement.textContent = songName; >> } else { >> nameElement.setAttribute('data-l10n-id', 'unnamedSong'); >> } >> >> ------------ >> >> This of course may happen to Notification, or Bluetooth connection where >> we may have a name of the device, or want to pass a localized version of >> the string "unknown device". >> >> Over time, I developed a convention in which I pass an argument of type >> L10nID which can be one of: >> >> 1) 'id' >> 2) {id: 'id', args: {}} >> 3) {raw: 'string'} >> 4) {html: 'html fragment'} >> >> The first is just a shortcut to the most commonly used scenario where you >> just pass a string with an ID of the entity. >> >> Second is the second most common scenario where you need to pass an >> id/args pair that will be resolved by L20n. >> >> Third is the scenario in which a raw string is to be used, and fourth is >> for HTML scenario. >> >> This allows to write easy code like: >> >> function updateTitleField(l10nId) { >> var titleElement = document.getElementByid('songTitle'); >> >> localizeElement(titleElement, l10nId); >> } >> >> function localizeElement(element, l10nId) { >> if (typeof l10nId === 'string') { >> element.setAttribute('data-l10n-id', l10nId); >> } else if (l10nId.raw) { >> element.textContent = l10nId.raw; >> } else if (l10nId.html) { >> element.innerHTML = l10nId.html; >> } else { >> document.l10n.setAttributes(element, l10nId.id, l10nId.args); >> } >> } >> >> --------------- >> >> This pattern is super helpful as it standardizes code localization and >> once a developer is familiar with how L10nId object may look like its easy >> to work with across different code pieces. The localizeElement I usually >> implement is not full (the 'html' scenario is rarely used) but it works >> well because it is easily extensible (for templating we could add template >> arguments to 'html' scenario, or add another one). >> On top of that the fact that the string scenario is resolving to entity >> ID means that the API promotes writing localizable code which is one >> feature I find very important when designing API's - it should suggest the >> right solution by making it the easiest. >> >> I started using it across many apps and started thinking about adding it >> as a helper to l20n.js. While I don't think that there's a value to add a >> class type because it would just increase memory cost, I think that having >> such localizeElement in our DOM API would help developers use L10nID >> approach. >> >> It also means that it will be easier to transition to l10n-id once we >> standardize, or make any other alternations since the API is more >> centralized. >> >> What do you think? >> zb. >> _______________________________________________ >> tools-l10n mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/tools-l10n >> > > _______________________________________________ tools-l10n mailing list [email protected] https://lists.mozilla.org/listinfo/tools-l10n
