Welcome to MUGS ⚄♠♞🏹 (Multi-User Gaming Services)! | github.com/Raku-MUGS | v0.1.4 has been released! (github.com/Raku-MUGS/MUGS/blob/mai...v0.1.4.md) | This channel is logged for historical purposes; logs at irclogs.raku.org/mugs/index.html
Set by japhb on 3 March 2024.
japhb OK so: I've had a bit of time to look through the rrp repo. It seems that the first problem you solved (string translation) was actually the problem that I had recently spent a lot of time solving for MUGS-UI-TUI (and a somewhat more advanced form in Terminal-Widgets, which MUGS-UI-TUI is based on). 04:39
I hadn't had a chance yet to merge all the functionality of that back to MUGS-UI-CLI, but for an example of what it looks like now, see: github.com/Raku-MUGS/MUGS-UI-TUI/b...nu.rakumod 04:43
Note the ¿ marks -- those are strings marked as translatable, and automatically translated when used.
However, because I wanted to look at the UI translation problem without a lot of history, I started from scratch in my file design. Your use of POFile is a good point though -- I should provide a way to simply load a POFile for the user's current language (user locale is switchable on the fly in Terminal-Widgets) and use that for translation. 04:45
As a general note, in MUGS the Client and Server should not have any *internal* translation needs, unless you plan for *developers* and *server admins* to be able to do so entirely in their native language. Otherwise every error string or status update or whatever should be sent back and forth as a semantic value (perhaps an enum or a moniker) that is translated in the UI. 04:49
And even if you do want server admins to be able to do so in their native language, it would be better to design an admin app that does that, rather than having Server or Client classes do translation. 04:51
(The one exception that I can see for the above is offering a plugin that runs in the server context and does online translation (via e.g. Google Translate API) for messages sent between players ... but that's not actually translating anything in the Server or Client Game, just offering a plugin to massage human messages sent *through* the Server.) 04:54
All of which is to say: My biggest suggestion would be to focus on the game's *semantics* so that I can have time to take the translation system that I designed for MUGS-UI-TUI/Terminal-Widgets and port it to MUGS-UI-CLI. I expect it will save you lots of mess in the long run. 04:56
And as for testing, I think the main trick will be to test the Server Game's behavior in isolation, the Client Game's behavior in isolation, and then do your first integration test with: Test Suite <-> Client Game <-> Server Game 04:58
That way you can test the semantics of the game completely separately from any UI. 04:59
Once those are trustworthy, *then* you can start testing one (or more) of the UIs. :-)
greenfork It's a good point that translation should happen on the UI layer 05:45
I think I intend to use the Pop game engine as a UI layer. I want to ship games to Windows, so any terminal interaction is not going to be easily digestible 05:47
I saw some work on the Pop UI layer, I will probably try to start there once I get Pop installed, so far I can't gitlab.com/jjatria/pop/-/issues/1 05:48
About testing: I think I will need a barebones example of how to do integration testing. I can unit test specific parts of my Client or Server implementation 05:50
but I don't fully understand what the entry points are to the whole program 05:51
If you could provie an example, it would be very appreciated, I can start from there
patrickb that pop error seems to be a rakudo or even MoarVM bug. 07:16
09:34 lizmat_ left, lizmat joined 10:02 lizmat left 10:04 lizmat joined 10:12 lizmat left 10:32 lizmat joined
greenfork patrickb: Okay, I will ask in the main channel, thanks for looking into it 12:11
21:52 lizmat left, lizmat joined 22:11 lizmat_ joined 22:15 lizmat left