14:58:30 <richard> #startmeeting TOr Browser Weekly Meeting 2023-03-27
14:58:30 <MeetBot> Meeting started Mon Mar 27 14:58:30 2023 UTC.  The chair is richard. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:58:30 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:58:34 <richard> nailed it
14:58:36 <dan_b> o/
14:58:42 <richard> pad: https://pad.riseup.net/p/tor-tbb-keep
14:58:43 <boklm> o/
15:01:05 <donuts> o/
15:03:49 <richard> ok everyone
15:04:21 <richard> we have 1 week until our s131 deadline
15:04:47 <dan_b> oh wow
15:04:49 <richard> realistically this means we should have builds ready to go no later than mid-day Friday
15:05:39 <richard> we had some issues with the updater and mar generation but they have seemingly been resolved
15:06:11 <Jeremy_Rand_36C3[m]> Safe to assume that anything linux-arm related will probably not happen this week, since you'll all be busy with the deadline?
15:06:31 <richard> so basically we're only taking the most minimal and/or verifiable fixes this week
15:06:48 <Jeremy_Rand_36C3[m]> Yeah that answers my question :)
15:06:57 * Jeremy_Rand_36C3[m] will wait till next week then
15:07:11 <richard> jeremy: yeah pretty much, then the next week we have the our regularly scheduled releases
15:07:28 <Jeremy_Rand_36C3[m]> cool cool
15:07:32 <richard> i saw boklm was able to build your openssl arm patch
15:07:38 <richard> which is ngl pretty exciting
15:07:41 <Jeremy_Rand_36C3[m]> 'tis a good problem to have though
15:07:52 <PieroV> (we've been lucky and pwn2own hasn't found anything on Firefox - it seems -, at least we don't have extra releases)
15:07:53 * dan_b has been on s30 work. is there anything s131 rlated this week i should be looking at instead?
15:08:01 <boklm> yes, I think only squashing/rebasing the patch is needed before merging
15:08:19 <Jeremy_Rand_36C3[m]> richard: ah cool, good to hear he got it to build
15:08:20 <richard> nope, dan_b and henry-x should stay on with s30 stuffs
15:08:31 <Jeremy_Rand_36C3[m]> boklm: oh cool. Want me to squash it and rebase on `main` this week while you guys are busy?
15:08:33 <dan_b> 👍
15:08:58 <richard> donuts: I presume the april 17th deadline is still in effect for the next round of user testing?
15:09:11 <boklm> Jeremy_Rand_36C3[m]: yes. I think rebase does not have conflicts, so should be pretty easy.
15:09:20 <donuts> richard: yep, sure is
15:09:37 <richard> alright excellent
15:09:49 <Jeremy_Rand_36C3[m]> boklm: excellent, will do
15:09:50 <richard> we can dive deeper into s131 stuff after this meeting
15:10:01 <richard> PieroV: so i'll hand over to you and your discussion topic
15:10:13 <Jeremy_Rand_36C3[m]> boklm: just to verify, is force-pushing OK, or should I open a 2nd MR?
15:10:30 * Jeremy_Rand_36C3[m] isn't totally used to post-GitLab-migration workflow yet
15:10:40 <boklm> Jeremy_Rand_36C3[m]: yes, force pushing in the same MR is fine
15:10:46 <Jeremy_Rand_36C3[m]> boklm: got it, thanks
15:11:03 <Jeremy_Rand_36C3[m]> Quite happy that that particular workflow aspect is more natural now
15:11:12 <PieroV> For my discussion point
15:11:30 <PieroV> We're going to need some new strings to translate in base browser
15:12:12 <PieroV> From a developer point of view, the strings commit approach isn't great, but if the fixup are handled correctly, at least we shouldn't have conflicts
15:12:36 <PieroV> Some commits won't be self-isolated, but will depend on the strings commit
15:13:46 <PieroV> Not adding more base browser files could be appreciated by translators, which will find all the bb strings in a single place, and by emmapeel, that won't need to setup more components for the browser with a handful strings each
15:14:28 <PieroV> So, initially we didn't want to have a strings commit again, and probably would still avoid if possible, but is there a strong reason not to have one?
15:15:26 <richard> so in this ideal future where tor-browser's strings are all converged, we'd have some base-browser strings file and a separte tor-browser strings file, each added in appropriate commits?
15:16:16 <PieroV> Yes, only two files, in one commit each
15:16:31 <PieroV> That contains the file, and the stuff to add it to the needed places (e.g., browser.xhtml)
15:16:44 <richard> presumably fluent?
15:17:01 <PieroV> Yes. We already have a Fluent file for the language notification
15:17:11 <richard> sounds good to me
15:17:17 <PieroV> I was thinking that maybe we could promote it to be the base-browser file
15:17:19 <richard> i'm excited for a simpler future for localization
15:17:34 <PieroV> And see if we can just rename the file, without losing the status of reviewed strings
15:17:42 <richard> does this affect android at all?
15:17:51 <PieroV> Then we can manage whatever needed on our side
15:18:06 <richard> hm in theory localization memory should prevent any string loss but obviously loop in emmapeel before we do antyhing
15:18:11 <PieroV> richard: uhm. So, I think we don't inject translations on GV at the moment
15:18:25 <PieroV> But theoretically yes, it does affect Android
15:19:02 <PieroV> All the UI should be on Fenix, but maybe some small UI pieces are also in Firefox
15:19:24 <PieroV> But usually they have a Java counterpart, so not translating GV could still work
15:19:45 <PieroV> I think we've never actually deepened the question, but we have never received an issue, either
15:20:15 <richard> ok
15:20:30 <PieroV> We could keep the .properties files as they are for now
15:20:51 <PieroV> Since they are already translated in a lot of languages and reviewed, etc etc etc
15:21:00 <PieroV> Especially if fluent is going to be our future
15:21:20 <PieroV> We're going to need this soonish, for the new lb notification
15:22:46 <richard> ok
15:23:03 <richard> sounds like a plan then
15:24:25 <richard> do we have anything else to discuss?
15:24:34 <Jeremy_Rand_36C3[m]> Nothing from me
15:24:39 * PieroV neither
15:25:21 * boklm neither
15:25:25 <richard> ok then
15:25:30 <richard> have a good week everybody o/
15:25:34 <richard> #endmeeting