[PSA] Fluent can now be used to localize UA Widgets

Hi all, Thanks to the work of James Teh [:Jamie] in bug 1659625, you can now use Fluent to localize UA Widgets. You'll need to create a custom `DOMLocalization` or `Localization` instance, and use `connectRoot` and `disconnectRoot` to integrate it into the UA Widget's lifecycle. An example of

Firefox Nightly Fluent core moved to Rust

Hi all, This is a PSA about the change that landed last night in bug 1560038 [0]. We migrated the core of Fluent Localization System in Gecko from JavaScript [1] to Rust [2]. The expected benefits are: - Lays groundwork for shared memory for Fluent (Fission) (next steps in bug 1613705 [3]) -

Semantic Locale and Language management in Gecko

Hi all! If you ever need to work with language/locale identifiers, we now have a clean API to use for all Rust, C++ and JavaScript. The most common scenario in which you may encounter the need is when you want to verify that, say, Firefox UI locale is English, or that the regional variant is

Deprecating DTD for localization in Firefox UI

Lodolo - Jared Wein - Gijs Kruitbosch - Edward Lee - Axel Hecht - Staś Małolepszy - Zibi Braniecki [5] https://bugzilla.mozilla.org/show_bug.cgi?id=1579477 [6] https://bugzilla.mozilla.org/show_bug.cgi?id=1501881 [7] https://bugzilla.mozilla.org/show_bug.cgi

Updates to mozilla/intl/mozILocaleService and mozilla/intl/mozIOSPreferences

Hi all, A quick update on the LocaleService and OSPreferences APIs. We just landed an update [0] that utilizes recently introduced new XPIDL feature of handling Arrays[1]! That means that we were able to turn all `getX` and `setX` methods into properties, which means that instead of

[L10n][BiDi] Fluent now controls content directionality

Hi all, A small update from the Fluent world - with landing of bug 1480798 Fluent now controls the directionality of its roots. That means that you don't need to do any special magic for RTL locales, as we will set `localedir` and `dir` (XUL and HTML) attributes on the document element and flip

Pseudolocalization in Firefox Nightly!

Hi all! We've just landed a new hot developer-oriented feature in Firefox Nightly - Pseudolocalization. Pseudolocalization allows developers to quickly test their UI against fake localizations helping us discover internationalization issues earlier in the cycle. You can find an introduction

Everything you always wanted to know about I18n/L10n/L12y, but....

Hi! I'm very proud to introduce the latest addition to our family of "explain ourselves" efforts - shiny, new developer docs about locale management, internationalization and localization practices at Mozilla. https://firefox-source-docs.mozilla.org/intl/index.html We put a lot of effort to

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

On Thu, Mar 8, 2018 at 7:09 PM, Bobby Holley wrote: > I just looked at the first 10 methods/attributes on that interface. None > of them are remotely performance-sensitive, and several are test-only. If > we see certain methods on it show up in profiles, we should move

BCP47 normalization of Language Tags in Gecko/Firefox

Hi all! A couple changes just landed in Gecko that will tighten our handling of language tags and locales to BCP47 standard. tl;dr: - Use mozilla::locale::Locale for any operations on Locale codes in C++ - Expect LocaleService::NegotiateLanguages to return canonicalized BCP47 langauge tags ==

Re: `general.useragent.locale` is no more. All hail `intl.locale.requested`

ce.cpp#l75 On Tue, Dec 5, 2017 at 3:47 PM, Mike Hommey <m...@glandium.org> wrote: > On Tue, Dec 05, 2017 at 03:15:06PM -0800, Zibi Braniecki (Gandalf) wrote: > > Hi all, > > > > We just landed a major patch which replaces `general.useragent.locale` > pref &g

`general.useragent.locale` is no more. All hail `intl.locale.requested`

Hi all, We just landed a major patch which replaces `general.useragent.locale` pref with a new pref `intl.locale.requested`. Historically, `general.useragent.locale` has been widely used to set a locale for Firefox UI. This year, we introduced a full new API called mozilla::intl::LocaleService

Re: Building mozilla-central with clang + icecream

Unfortunately, that still doesn't make it fly. My mozconfig: ``` ▶ cat .mozconfig mk_add_options MOZ_MAKE_FLAGS="-j$(icecc-jobs)" mk_add_options 'export CCACHE_PREFIX=icecc' mk_add_options "export RUSTC_WRAPPER=sccache" mk_add_options 'export CARGO_INCREMENTAL=1' mk_add_options 'export

Re: Building mozilla-central with clang + icecream

On Tuesday, November 7, 2017 at 2:54:45 AM UTC-8, pa...@paul.cx wrote: > I'm using this setup daily (with clang trunk from some weeks ago, not > 5.0, but it's the same really), here is my mozconfig: > > ``` > export CC="icecc clang" > export CXX="icecc clang++" > mk_add_options

Re: Pulsebot in #developers

+1 The only thing I'd like to see from pulsebot on developers is: "26 commits have been merged from autoland into mozilla-central. List: http://...; zb. ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: Intent to implement: ScrollTimeline

Is it possible to use this, or is there a similar proposal, for linking animation timeline to other user-controlled means of interacting with the UI? I'm thinking primarily about things like: - drag - the percentage of the distance between the source and target linked to the animation

Re: So, what's the point of Cu.import, these days?

On Tuesday, September 27, 2016 at 2:01:09 PM UTC-7, David Teller wrote: > "why": because you wrote "The former is a more tricky." in your previous > message. If it's not, I'm quite happy to not remove them :) > > For reference, "the former" is a snippet such as: > > if (needed) { >

Re: So, what's the point of Cu.import, these days?

On Tuesday, September 27, 2016 at 2:28:54 AM UTC-7, David Teller wrote: > If I understand ES6 modules correctly, two imports from the same webpage > will return the same module instance, right? I don't think this is a correct statement across globals. When you load two modules in one js context,

"non-missable" events, or multi-promises

There seem to be an interesting section in Promises doc from 2001 about multi-state promises - https://www.w3.org/2001/tag/doc/promises-guide#state-transitions One of the things that we are working on is a spec for loading localization resources into HTML, which resembles the example from this

Re: "non-missable" events, or multi-promises

On Tuesday, September 22, 2015 at 3:02:21 AM UTC-7, smaug wrote: > That document is from 2015 ;) Oh. Fun! > The example in that chapter is "This property should return the same promise > every time it is retrieved, until the image moves backward from the > loaded state into the unloaded state.

Platform help needed for Firefox OS L10n/Intl

Hi all, There are two things in the platform that need a developer, which would significantly help Firefox OS L10n/Intl work. 1) Move navigator.mozHour12 to platform This is a shim [0] that currently requires us to give all apps that want to properly display time to elevate its privileges to

API request: MutationObserver with querySelector

Hi, One of the major use cases for MutationObserver is all kinds of libraries that either shim APIs or provide intrinsic modifications to DOM experience. Examples of such libraries may be: * A library that provides Date/Time pickers only caring about * A library that extends behavior of a

Re: Allowing web apps to delay layout/rendering on startup

On Friday, August 14, 2015 at 3:59:23 PM UTC-7, James Burke wrote: There does not seem to be a need for extra APIs in the browser for controlling layouts or paints using this approach: Great work James! I like that we can play with this approach right now, but I'm wondering if we should still

Re: Allowing web apps to delay layout/rendering on startup

I'm not sure if the multiple-meta solution is going to be really working well. From the perspective of a gaia app developer that means that he has to inject manually a new meta for every library he wants to use. That feels weird. I would rather expect a single meta that app controls fully,

Re: Allowing web apps to delay layout/rendering on startup

On Sunday, August 2, 2015 at 10:47:26 PM UTC-7, Wilson Page wrote: Are we expecting that this will reduce unwanted layout/paint cycles on the critical path and thus minimise the 'white flash of doom'? Absolutely. I believe that that's the primary goal, to replace the current race condition

Re: Allowing web apps to delay layout/rendering on startup

On Sunday, August 2, 2015 at 2:03:28 AM UTC-7, Robert O'Callahan wrote: On Sun, Aug 2, 2015 at 11:58 AM, Zibi Braniecki wrote: So maybe we would need another event that the website fires to indicate when it for paint/cache/screenshot. Assuming pages have an easy way to block the 'load

Re: Allowing web apps to delay layout/rendering on startup

On Saturday, August 1, 2015 at 3:01:39 PM UTC-7, Jonas Sicking wrote: On Sat, Aug 1, 2015 at 12:30 PM, Zibi Braniecki wrote: 2) We want to bring app to foreground/paint it only when the app's chrome is visually complete. I would very much want this. Right now, during a navigation from

Re: Allowing web apps to delay layout/rendering on startup

This is something I've been asking for for quite a while. We have this state with runtime localization where we have to do backflips in order to win the race with Gecko to firstPaint. I filed a bug for getting an API to prevent frame creation [0] and got a response that display: none should do

Re: Mutations from Parser handled after DOMContentLoaded?

On Monday, July 6, 2015 at 12:48:33 PM UTC-7, smaug wrote: I don't know what have a MO set on the document during readyState=loading actually means. Document has three loading states - loading, interactive, complete[0]. I'm initializing MO during loading stage, so that I have a chance to

Mutations from Parser handled after DOMContentLoaded?

Hi all, I have a question about MO behavior. From what I understand, MutationObserver API is designed in a way that is supposed to guarantee two things that I need: 1) That if I have a MO set on the document during readyState=loading, then all consequent elements injected by Parser into DOM

Re: Mutations from Parser handled after DOMContentLoaded?

We took it to the stre... IRC, and in result of that I filed to bugs: 1) https://www.w3.org/Bugs/Public/show_bug.cgi?id=28920 2) https://bugzilla.mozilla.org/show_bug.cgi?id=1180927 zb. ___ dev-platform mailing list dev-platform@lists.mozilla.org

Should MutationObserver ensure HTML file nodes are run through it before they're injected in DOM?

I'm trying to use MutationObserver to do runtime localization of the nodes that are provided by an HTML file. I register the mutation observer on document at it's readyState=loading and in result all nodes that are in HTML files are reported to my callback. That's cool. Now, usually,