21:51:44 RRSAgent has joined #dom-localization 21:51:48 logging to https://www.w3.org/2025/11/10-dom-localization-irc 21:51:48 RRSAgent, do not leave 21:51:49 RRSAgent, this meeting spans midnight 21:51:49 RRSAgent, make logs public 21:51:51 Meeting: DOM Localization 21:51:51 Chair: eemeli 21:51:51 Agenda: https://github.com/w3c/tpac2025-breakouts/issues/67 21:51:51 Zakim has joined #dom-localization 21:51:52 Zakim, clear agenda 21:51:52 agenda cleared 21:51:52 Zakim, agenda+ Pick a scribe 21:51:54 agendum 1 added 21:51:54 Zakim, agenda+ Reminders: code of conduct, health policies, recorded session policy 21:51:54 agendum 2 added 21:51:54 Zakim, agenda+ Goal of this session 21:51:55 agendum 3 added 21:51:55 Zakim, agenda+ Discussion 21:51:55 agendum 4 added 21:51:56 Zakim, agenda+ Next steps / where discussion continues 21:51:58 agendum 5 added 21:51:58 Zakim, agenda+ Adjourn / Use IRC command: Zakim, end meeting 21:51:58 agendum 6 added 21:51:58 breakout-bot has left #dom-localization 23:35:51 saji has joined #dom-localization 23:36:21 xfq has joined #dom-localization 23:36:27 present+ 23:38:44 RRSAgent, make minutes 23:38:45 I have made the request to generate https://www.w3.org/2025/11/10-dom-localization-minutes.html xfq 23:38:55 mjackson has joined #dom-localization 23:39:02 RRSAgent, make log public 23:39:03 RRSAgent, make minutes 23:39:05 I have made the request to generate https://www.w3.org/2025/11/10-dom-localization-minutes.html xfq 23:39:17 present+ eemeli, martin 23:39:48 berlysia3 has joined #dom-localization 23:41:24 present+ Rob Wu 23:41:39 robwu[m] has joined #dom-localization 23:42:23 eemeli: blah blah etc. 23:42:27 s/eemeli: blah blah etc.// 23:43:12 present+ mjackson 23:43:15 present+ berlysia 23:43:35 eemeli: (intro) from Mozilla, chairing the session 23:43:49 martin: chair of Internalization interest group 23:43:59 robwu: from Mozilla working on WebExtensions 23:44:15 present+ Carlos 23:44:21 present+ saji 23:44:47 scribe+ robwu[m] 23:44:51 scribe+ xfq 23:44:56 carlos: working on WebExtensions 23:45:00 xfq: Fuqiao Xue, W3C i18n lead 23:45:31 others introduce themselves: Fuqia (saji on IRC), Ryusei, Daisuke, Mike 23:46:10 RRSAgent, make minutes 23:46:12 I have made the request to generate https://www.w3.org/2025/11/10-dom-localization-minutes.html xfq 23:46:34 present+ Thomas 23:48:22 eemeli: (introduces MessageFormat and localization) 23:50:13 tomayac has joined #dom-localization 23:50:22 Present+ Thomas_Steiner 23:50:29 present- Thomas 23:50:33 eemeli: 95-98% localization addressed by existing solutions; But we should not use "Number of unread messages: 3", but "You have 3 unread messages" (with many locale-specific variants) 23:51:25 eemeli: platform-specific differences, locale-specific differences not even known to the original developer creating a string 23:53:03 eemeli: E.g. in Finnish, he and she have the same word. We use suffixes to modify meanings of words. Localizations to Finnish use unnatural ways 23:54:09 eemeli: We are here today because we want to build systems to help with doing localization, helping people with finding this as the easy solution to serve their needs 23:54:51 duerst has joined #dom-localization 23:55:45 eemeli: Fundamental part of this work, in 2019, in JavaScript and the web platform, none of the existing formats support all needs of localization. MessageFormat working group part of unicode ... committee, working on Unicode MessageFormat spec, finished earlier this year 23:56:50 eemeli: (...) not just important; interaction with HTML is also important, file format also needed 23:57:11 eemeli: at Mozilla we are well positioned for this, because this is already how we are localizing Firefox, Thunderbird, our products 23:57:21 slides: https://docs.google.com/presentation/d/1ON2yeocyDSVr8r0cg8ZlhgpFfsvloznq1pJqYSADJs8/edit?usp=sharing 23:57:40 eemeli: (points to screen showing example of what it looks like in Firefox) 23:58:44 eemeli: reference to established messages, data-l10n-id in HTML to refer to messages in the loaded resources, data-l10n-args to pass arguments to localized messages. Combined with ftl file 23:58:58 ... term reference in ftl file 23:59:32 ... example of pluralization support in the ftl format 00:00:49 thomas: I learned the hard way that plural is not as simple as singular, plural 00:01:42 eemeli: the example I copied in the doc uses the literal value "1", but in practice many use O and I 00:02:00 eemeli: the example shown is how it works in Firefox. Not exactly what we will be proposing, but pretty close 00:02:33 eemeli: we made choices in Firefox that we would have done differently today; these learnings we also apply here 00:04:01 thomas: CSS content localization? 00:04:11 carlos: CSS with attr() can be used 00:04:59 thomas: Does not work in all scenarios 00:06:27 eemeli: envisioning that the system works in the client, but can also be used in server-side rendering if desired 00:06:44 Would need to look into it in more detail, but `::scroll-marker` might not work with `attr()`: https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Selectors/::scroll-marker 00:07:42 eemeli: in experience with Firefox and other products such as mozilla.org, these use the same localization system, and they end up doing a lot of the work in the client, which is enough 00:07:51 leo: biggest lessons? 00:07:54 present+ Leo Lee 00:11:01 eemeli: Biggest challenges in HTML part of it, async processes. Localization resource marked as potentially needed. When formatting, the formatting call is async. Processes resources async, need fallback processing, which can end up resetting the locale; ... may require loading many files from disk or network. Adding complexity to functions needing to be async. This is the biggest challenge in Firefox 00:11:49 ... data-dash is used as a prefix, but on the web we could define an attribute for that 00:12:36 ... (showing example on screen) Same example as before, but without data- prefix, and arguments with prefix as attribute name 00:14:11 ... different syntax as Fluent. Need a file format. Challenge with existing format such as JSON is that it does not support newlines in JSON. In MessageFormat simple syntax can need multiple lines, in JSON it could be on one line with a separator, but becomes unreadable. 00:16:39 ... Big questions: (1) Should we do this? (2) Is Internationalization WG the right venue for the file format, or is there a better place? (3) Where do we draw the line where this can do work? E.g. CSS example we just discussed. There are ways we can make it work, but maybe not the same mechanisms we want for the web platform. Do we want to build a general purpose tool or something specific for localization? In the spec translatable 00:16:39 attributes. Being able to specify class name of element could be powerful, but maybe too powerful. Capabilities for edge cases 00:17:13 thomas: legal requirements, in EU cookie banner may be needed, in other locations not needed, is that too much for this proposal? Having on/off switch for a block 00:17:36 eemeli: specific to locale, not localization 00:17:56 xfq: some markup specific to locales, can it be there? 00:19:08 eemeli: What sort of transform are we comfortable introducing? E.g. cookie banner dialog could have a custom element that might or may be included, and in the localization we can conditionally show it 00:20:16 ... this discussion has not happened yet. Figuring out the next steps and places for this next steps 00:21:03 ... Maybe a W3 group for File format, Unicode not a fitting place for it 00:23:36 that's kind of related to our guidelines at https://www.w3.org/TR/localizable-manifests/ 00:25:14 eemeli: on big question 1, answer probably yes (we should work on localization as a capability of the web platform) 00:25:24 leo: what does the fallback logic look like? 00:25:29 carlosj4 has joined #dom-localization 00:26:19 eemeli: Details to be specified. In Firefox we have a solution that works for Fluent. We started with a system where we load a resource, if it is missing we get a 404 internally, but consider that locale as a whole to be corrupt, and switch to a completely different locale, but turns out to be a bad failure mode 00:26:48 ... what we do currently, if no resource is available, we do fallbacks per individual messages 00:27:05 ... space for how much need to be specified in the standard, or left for the user of the system 00:27:29 RRSAgent, make minutes 00:27:30 I have made the request to generate https://www.w3.org/2025/11/10-dom-localization-minutes.html xfq 00:27:37 ... locale negotiation could be completely specified, or building blocks can be simple, simple for users to provide fallbacks 00:28:26 ... If we do preprocessing, then we do not need to do stuff at runtime, but removes flexibility for doing intelligent things at runtime 00:30:17 mike: Not clear to me client-side vs server-side. Examples of server-side plus client-side can help with making a case. Concerned about network traffic needed to include resources for different locales, more bits over the wire, memory usage, CPU usage, low end devices or bad connectivity. Also nervous about bundling HTML in the resource file (cookie banner example) 00:31:33 eemeli: related very closely to the question of how much power we want here. To reduce concern, elements could be limited to inline elements (no block-level elements). 00:31:59 RRSAgent, make minutes 00:32:00 I have made the request to generate https://www.w3.org/2025/11/10-dom-localization-minutes.html xfq 00:33:06 mike: Impact on performance metrics 00:34:00 ... capabilities all great, request to update explainer to clarify these details, when to choose one approach over another. E.g. image selection, how that affects ability to preload resources 00:34:26 eemeli: question of whether we do support live reload of language, or require a full reload 00:35:11 carlos: About the attributes, coupling the implementation with the locale file, elements/attributes being overwritten. Would it make sense for messages to be reused, to allow attributes to get a specific message directly 00:35:16 eemeli: we could do that 00:35:29 carlos: Would make it easier for devs to do community translations 00:36:06 eemeli: could require specific HTML opt in to declare which HTML attributes are localizable, aria-labels. 00:36:30 thomas: declarative shadow DOM; anything that could break? Probably fine, thoughts? 00:37:03 eemeli: I am not aware of places where it could break with declarative shadow DOM 00:37:24 ... conceptually do the same thing as with CSS, shouldn't break 00:37:57 carlos: How do you deal with DOM mutations, such as setting innerHTML or appending elements 00:39:07 mjackson has joined #dom-localization 00:39:38 eemeli: multiple options. Could be per-element when specific (data-)attributes change, or observing everything under the tree, preventing overriding elements underneath, whether we are interested in localization everything at once (localization frame)... no clear answer. Gut feeling is mutating localized DOM element without touching the localization attribute is fine 00:40:22 ... pre-existing content. Do we allow creation or removal, or re-ordering of elements 00:40:53 carlos: properties such as the innerHTML getter would return whatever was applied by localization? 00:40:56 eemeli: yes 00:41:41 thomas: blocking attribute maybe 00:42:26 eemeli: could also be a DocumentFragment that you then insert in the document 00:42:32 thomas: is it mentioned somewhere? 00:42:35 eemeli: I think so 00:43:25 carlos: How would you deal with changes to resource files in the header, dynamically? 00:43:50 eemeli: Treat as an async JS call, and/or emit an event whenever the current set of known localization resources have loaded 00:44:44 robwu: Something like Font loading API? 00:44:58 eemeli: not aware of that API, but could be 00:46:31 eemeli: on fallback, behavior should be user specifiable. 00:49:48 martin: On the question of whether the Internationalization WG is an appropriate forum. On paper I am a member of that group, but I don't participate much due to time zones. One thing to consider is that this would be a big item. The Internationalization WG may be more used to doing smaller things all over the place by necessity. They have bigger work items, but this is quite specific requiring internationalization, but also requires 00:49:48 not knowing just how HTML div works, but shadow DOM etc. 00:51:42 xfq: i18n group has incubated technical things in the past, and proposed to HTML 00:52:10 eemeli: We are at the end of the meeting, we should move over to the other room 01:06:05 RRSAgent, make minutes 01:06:06 I have made the request to generate https://www.w3.org/2025/11/10-dom-localization-minutes.html xfq 01:25:57 tidoust has joined #dom-localization 01:26:02 RRSAgent, bye 01:26:02 I see no action items