Support translations in abra
#483
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: toolshed/abra#483
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
toolshed/organising#640
Current progress: https://git.coopcloud.tech/toolshed/abra/commits/branch/weblate-first-steps
Potential libraries:
@3wordchant not exactly sure but I think that I need to be added as project admin on weblate to see more of the settings? i guess we can just merge whatever we have now and focus on the main branch. i'm just gonna go with
gotextand make a start.This is going fine. I struggled a bit to understand how to deal with the format handling when using our logging library /
fmtbut that is resolved now, I think. Luckily, our unit test suite explodes if I fuck up thegotext.Getcall, so that's keeping me in check. I think it will be another couple of hours of work and I'll have it covered.I'm not sure how the multi-line strings of the
Example: "..."/Long: "..."in the cobra CLI command definitions will turn up in the weblate UI but I hope this will be fine!One thought: we're threading output from the runtime into the deploy realtime status reporting. I think we should probably be catching those outputs and translating stuff we replace the output with. I don't think it will be too much work. In general, I think that output can always be improved, so will take a look at it again.
@3wordchant cool way to invoke
xgotext:87ebf66f0b/main.go (L3)these "magic comments" then get read bygo generateand invoked. kind of nice for helping dev folk run the generation without knowing all thexgotextmagic. let's try add this at some stage tocmd/.../main.go👀@3wordchant holy sheyat, witness this additional chaos:
8a2598a524/Makefile (L270-L291)they manage to specify the keyword of the function you use to mark the strings 🤯 I will try to wire up some Makefile magic so there is a "canonical" way of dealing with all the translation tools in-repository and hopefully this will then be possible to coordinate with weblate / drone CI / etc. Working on it...can you add @ChasquiLabo as a translator on weblate?
does this support translated abra commands?
something like:
@fauno still too early to do translation work just yet. will add weblate accounts ASAP once the dust settles
it seems that this might be a bit trickier than expected as I just realised that cobra itself (our CLI lib) is still not supporting translation: https://github.com/spf13/cobra/pull/2090 I hope I can override and/or help push this forward
i'm hoping we can translate the sub-commands, yes. working towards this now... do you also want to translate the flags used e.g.
--no-domain-checks?FYI I've already been running into nearly all the problems described in https://github.com/spf13/cobra/pull/2090#discussion_r1435606770 when making small changes and trying stuff out. I think it makes sense to refactor to use "keys" in the source code and then also have the
entranslators do the same workflow as the rest. I've seenxgotext/msgmergealready complain about formatting and quotes and such, so I think doing all translation work in a translation editor (poedit/weblate) will be more consistent in the long-term. This required more up-front work now but I'm fine with it.Back to trying to figure out how to translate sub-commands / flags / etc.
Anyone with experience doing this already, please let me know!
OK after some research, I don't see people doing this at all... do we have any references for tools that translate their sub-commands / flags? It seems like a very logical thing to want to do... I've raised https://github.com/spf13/cobra/issues/2301 against the CLI lib we use to see what they think!
OK, it's possible! I have a working example with fully translated sub-commands and help output.
I updated the ticket because it is not pretty https://github.com/spf13/cobra/issues/2301#issuecomment-3209828124
Now it's just a question of whether to do a large refactor in our codebase to accomodate this new way to initialise everything so that translation is present OR trying to get cobra to support initialisation in a more convenient way. I will try to judge which is a faster way through when I come back to this tmoro.
Wow incredible work @decentral1se 🤩
Thanks!
I think step one is to check if I can initialise the localisation function in a central place in the code base. We need
--keyword/--keyword-pluralarguments forxgotextfirst for that because it involves an non-standard import whichxgotextneeds to recognise. Starting to look into that in https://github.com/leonelquinteros/gotext/issues/124Then we don't do a tonne of
gotext.Getcalls but alang.G(or whatever) call. That is less verbose,xgotextcan pick it up and then the localisation (hopefully!) is always initialised when called. If this works, it would make it much less work to translate all the (sub-)commands...@3wordchant aight, #608 is merged 🎉 closing this one off.... things we still need to deal with:
abra.potis the "default domain".pofiles sit alongside it in this repositoryHit me up for a co-work if you like, or lemme know how you get on async whenever time allows.
PS. re: #483 (comment) I ultimately didn't go for the translation keys based on this thread which highlighted a lot of issues you can also run into. also it would be crazy work to replace all strings with a key. it seems like convenience of the developer / default locale is also something to keep in mind...
xgettext-gosolved all the issues I was facing...