Meeting started at 2024-05-13 07:00:36 UTC

The Meeting name is 'i18n'

Hello

hi

Parag is away. I'll take the chair today.

Hi

Hi

hi

hi

Let's get started.

Jens Petersen: Do you have any updates?

Short answer is no... when should we look at it?

Is there any new tickets for this in WG?

There are quite a lot of issue listed there, so maybe we need to prioritise and review them

No

I dunno if it makes sense to create i18n tickets for all of them (well maybe a subset)

Sure. it may be a good idea

Okay

Let me try to do it before the next meeting

Thanks!

Alright. let's move on.

I don't think we have any bugs we need to discuss around this.

As of today, we still have 21 bugs open for f38.

https://bugzilla.redhat.com/show_bug.cgi?id=2122022 (ax86-terminus-ttf-fonts) could proceed?

Okay. will take a look later.

Does this list become f39 or f40 tracker at some point?

I think there is some terminus-fonts package...

I think we will open another ticket when f38 is EOL'd and next target of EOL will be f39.

Please find some time to take a look at f38 bugs. otherwise they will be unfortunately auto-closed by 21st of May.

Is the ax86-terminus-ttf-fonts package related with the terminus-fonts package?

pwu: Please check the upstream url.

tagoh: Okay

Anything we want to highlight on f38 bugs?

Do we think https://bugzilla.redhat.com/show_bug.cgi?id=2178174 is still reproducible (flatpak ibus indicator)?

Hm, no, I can't. it looks good at the moment.

Aha

pwu: maybe libreoffice bugs can be bumped?

tagoh: then can close it I guess :)

Jens Petersen: Yep. I did just now. thanks.

Just a reminder to all, please also triage the bugs you had reported there

Jens Petersen: Maybe the libreoffice bugs are fixed in upstream.

aha

Basically we should either move or close the bugs ahead of EOL

It might be okay to let ABRT bugs to autoclose, but again they should really be looked over since they may contain useful info

I prefer to close the libreoffice as EOL.

I prefer to close the libreoffice bugs as EOL.

That is actually worse than saying fixed upstream

I think it would be good to add some comments even if you want to move it to upstream.

Okay, maybe I will close it after the meeting...

The important thing is to close the loop on these bugs, not to fix them now in f38

I prefer to close the libreoffice bugs as EOL.

For the libreoffice bugs.

fujiwara: is there any open upstream issue for vte surrounding text?

most of f38 bugs are reported through abrt. maybe hard to reproduce I guess... let's check with the reporter if not yet. if not sure, maybe good to try bump if it is not yet. otherwise maybe close them as currentrelease ?

Let's move on to the next topic.

Kan-Ru Chen:)

Oops, wrong link

I created the Change draft here https://fedoraproject.org/wiki/Changes/IBusChewingForZhTW

I think I'll mark it as ready for Wrangler after meeting

Kan-Ru Chen: sounds good to me anyway

Kan-Ru Chen: How to try the new ibus-chewing package?

There were many bugs of vte and closed. Currently I have https://gitlab.gnome.org/fujiwarat/vte/-/merge_requests/1

fujiwara: aha

pwu: rawhide has ibus-chewing 2.0.0 and https://copr.fedorainfracloud.org/coprs/kanru/libchewing-git/ has the upcoming libchewing 0.8 release

Kan-Ru Chen: maybe good to add it to the proposal page?

Kan-Ru Chen: Thanks!

Kan-Ru Chen: when do you plan to decide the final version for F41 btw? Maybe depends on upstream progress?

yeah, it will depends on upstream progress. If no serious bugs were reported then new feature development will pick-up sooner.

Dunno if there are any more considerations for users migrating from ibus-libzhuyin in terms of usage?

Kan-Ru Chen: would be good to decide on the final version in the Change later

(I don't mean "forced migration", more just in adoption or "getting used" to ibus-chewing)

I'll clarify in the change.

Cool thanks

Anyway thanks for putting it all together, you can tweak make tweaks after submitting, but I think it is ready enough

Anyway thanks for putting it all together, you can _still_ make tweaks after submitting, but I think it is ready enough

Is there anything else we want to *evaluate* to accomplish this Change?

I think fujiwara suggested to refresh the old QA:Chewing testcase

From here I think it is really up to fedora user/community feedback and our testday etc

Commented old bugzila issue of vte. https://gitlab.gnome.org/GNOME/vte/-/issues/2065#note_1551816

As we have separate test case for engines, yeah, if we have updated test case for ibus-chewing that would be nice.

fujiwara: thanks

Kan-Ru Chen: one more small suggestion you could add a link to the i18n pagure ticket - that way it is clear the the Fedora i18n is aware of the Change

Kan-Ru Chen: one more small suggestion you could add a link to the i18n pagure ticket - that way it is clear that Fedora i18n is aware of the Change

Sure thing.

Cool, anything else to discuss about this ticket?

Let's move on if not.

Kan-Ru Chen: actually I added the pagure link now under #Feedback but feel free to edit of course

Jens Petersen: So do you want to say something about it?

ah

Well yes and no I guess... wondering what could be done

that sounds like a Qt issue though.

It looks like it needs Desktop environment support. As I also primarily use LC_ALL=en_US I found the same thing annoying. Maybe that could be an install/boot time option but changing it would need config change.

Yeah I agree

It is probably hard to get perfect solution but at least for GNOME/Gtk perhaps as a start

Well, there are some limitation to deal with non-rich text on en locale. there are no way to determine what those glyphs are supposed to be. there are some envvar to manage it but not in UI.

Right, so that is the topic here one can say

What kind if UI could be possible

What kind of UI could be possible

That may be non-rich text specific issue right.

Can you say about on "non-rich text" ?

Can you say more about on "non-rich text" ?

like something on a plain text editor

Ah no lang markup right

Yes

Right right

So is pango the right place to handle this?

There is some PANGO_LANGUAGE environment variable.

Yes and no? actually Pango has something but it won't work if application doesn't give anything.

more likely an application issue. e.g. if we want to make it better on gnome-text-editor, we need something in gnome-text-editor.

Maybe some gsettings variant of PANGO_LANGUAGE?

Hmm dunno if dynamically handling is realistic though

The most primitive thing would be to set PANGO_LANGUAGE in the Language/Region pane

dunno. if we want to do something with gsettings, we need to modify gtk?

Maybe

Language changes need restart again, hehe

Language changes need restart away, hehe

Dunno if there is some GNOMEy place to keep the envvar

and maybe pango too; I don't think PANGO_LANGUAGE related things are implemented as API

Right

Maybe we need to talk to the GNOME people

Right

Most apps don't like changing fonts anyway I feel

Alternatively in Fedora we could try to setup PANGO_LANGUAGE early on, possibly hmm - like Kan-Ru Chen also suggested

But getting to wider solution firefox would have to look at the envvar - I assume it doesn't??

Not much idea about Qt

But how? it may be a sort of user's interaction. it can't be done automatically because we can't rely on current locale. otherwise it should works without it.

Well maybe some advanced setting in anaconda or gnome-initial-setup/gnome-control-center

Well a simple PoC would be to make a config tool to generate the PANGO_LANGUAGE=...

Like "Preferred glyph variant for CJK unified ideographs"

Yea

We need a workaround like that for Qt.

Yes that would be good

spending a lot of time on the meeting, let's keep a discussion. not yet sure what should be the next step for this though.

sure

Anything else we want to discuss in this meeting?

Alright. let's stop here then.

Thanks everyone for the long meeting!