| 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
|
|||