This is going back for another round sorry just so that we/I can discuss this in a bit more depth.
Really after looking at this for some time the big question is whether this should be a moodle component or not.
As David suggested early on if all that is required is translation then no for sure this should be working through AMOS rather than through Moodle.
However after talking to Jermoe on Monday and thinking about it over the next day perhaps there is reason to have it as a core component.
So the initial questions I asked Jerome:
- Will the mobile client be connecting to a site to get language strings.
- Will the mobile client be able to connect to multiple sites.
- How will the mobile client collect these strings.
The answer to first two of these was yes and web servcies was how it was going to collect strings.
This immediately starts to paint a picture. We all know that a site can choose which lang packs are installed, and that the lang packs can be further customised by the administrators.
This gives the mobile app the same feature set available to site. Language strings will be customisable through the site and the site will be able to control the language packs available.
It also however is going to enforce a few things on the mobile app.
- First it will have to fetch the strings to each site it connects to, it wont' be able to reuse strings between sites because they may have been customised.
- Second because WS are going to be used for the strings the mobile client isn't going to know when strings have been changed. The site obviously uses its cache which gets purged when changes are made however thats not possible for the client I imagine so you are going to need to have something like a time based cache and refresh the strings at some point. Perhaps when the client connects is enough, I'm not sure you tell me.
So the next big question is (Juan or Jermoe can you please answer):
- Are these features that you want for the mobile client or are these unplanned features that you've inherited throught he process of creating a core component.
To prompt a little more discussion and thought as well: while talking to Petr about this change he raised the fact that many of these strings exist in this lang file without context. What he is getting at is that many of the string have been taken from one lang file or another and copied here for the purposes of the mobile app. A string can mean one thing in one context and something entirely different in another context and you've got
Now - after thinking about all of that the following occurs to me. It appears there is a point of separation here.
The "features" discussed above seem pertinent in some situations but not others.
You've got string relating to two things, the first you've got strings required for the mobile client, and second you've got strings relating to Moodle content.
The mobile client strings are strings like "csssynced". That has nothing to do with the Moodle site the client has connected to.
Moodle strings are strings like "sitename". This string needs to come from the Moodle site that the client is connected to. The string itself comes from a lang pack, can be translated, and can be customised by the admin.
Again digging into this your client may be set to use French and you may want to be using French lang strings where possible. The site you connect to may only have German installed. You don't want to change everything on the mobile app and throw the user entirely off (they may not know a word of German) you want to show just the content in the available language.
Get the drift?
So as an idea, what about the following:
Mobile client language strings coming from AMOS. I'm sure David will be needed for this, he's the translation master here.
Site content coming from the context it is being used in. No new component, no new strings, just what is available.
The biggest issue to this is no doubt the Moodle version and knowing what strings are available. Not sure how you are getting around that, I suppose you will have a good idea however as no doubt this is something you've encountered before.
Now all of that and I've got no clue what you're up with the mobile app. So feel free to tell me I've got it all wrong, but if you do explain yourself in depth so that myself and everyone following this understands.
In regards to the actual code - please ensure if we do add a new component in the end that you run all unit tests. We've got component counts etc in place to make sure we don't add core components unless 110% necessary.
Many thanks for the hard work and sorry about the bloated comment.