Would be good to have that, to be able to translate mobile app.

This is a blocker for mobile app, I changed priority to blocker to remind me do this ASAP

Seems you didn't find time...

Created a moodle plugin for translation: https://github.com/dongsheng/moodle-local_mobile

PS: I committed the change under Dongsheng name as I didn't change anything (if you have any issue with that Dongsheng, let me know ). The file will be edited by Juan the time going.

Juan can you check this file mobile.php and remove/edit the strings we need. Helen will peer-review the correctness of the English. This file currently contains the strings used by "My Moodle" app, so I guess most of them should be still valid for the HTML5 app. Thanks.

Hi Jerome,

at this time, I'm not sure which strings I need to remove, change or add.

I suppose we don't have to do this before code freeze? can we wait a couple of weeks?

My proposal is to add this file to core right now and then fix the strings in a couple of weeks.

Regards

Hi Juan,

Thanks for considering this issue. As far as I know, it doesn't have to be done before code freeze.

I suggest we fix the strings before adding it to core, just in case there are strings which are no longer used which need to be removed. Some translators are very keen, and start translating stuff as soon as it's added to core, so best to fix things first!

Adding Jerome as a watcher.

Hi Helen,

please, can you review the strings here?

https://github.com/moodlehq/moodlemobile/blob/master/lang/en.json

Once reviewed, I will create the mobile.php file

Hi Juan,

Thanks for asking me to review the language strings. I found them almost perfect, just needing a little polishing. Also, as I mentioned in a chat, we try not to use the word 'Moodle' in lang strings, as some organisations call their moodle site something different.

Here is my list of polished strings:

"addedtoqueue": "You are offline; your operation has been added to the task queue.",
"cannotaddnote": "Network not reachable. Your note has been saved in task queue; you can resend it once you are online.",
"cannotconnect": "Cannot connect: the site must use Moodle 2.4 or later.",
"cannotsendmessage": "Network not reachable. Your message has been saved in task queue; you can resend it once you are online.",
"contentyetnotavailable": "This type of activity is not yet available via the mobile app.",
"dodeletesite": "Yes, delete this site completely.",
"enableautosynccss": "Enable synchronization of additional CSS style sheet",
"enableautosyncws": "Enable synchronization of operations and data",
"filenotsyncyet": "File not yet synchronized (no local copy available).",
"fileurl": "File URL",
"forcecsssync": "Force CSS sync now",
"invalidaccount": "Please check your login details or ask your site administrator to check the site configuration.",
"invalidscheme": "Please provide a valid site URL.",
"invalidsite": "The site URL is invalid.",
"moodlehelp": "Help",
"notificationsnotsupported": "Notifications are not yet supported on Android systems.",
"offlinemode": "Offline mode",
"openinmoodle": "Open this module",
"requiredfields": "All required fields must be completed.",
"selectsite": "Select a site",
"siteexists": "This site already exists.",
"sitename": "Site name",
"therearentnotificationsyet": "There are not yet any notifications.",
"toolguide": "Tool guide",

I just created the mobile.php file and placed it in the lang/en subfolder.

The mobile.php is not displayed in the custom lang editing tool because there is not a subsystem called moodlemobile defined in the get_core_subsystems() function

In order to make available this file for translation we need to add a new subsystem called moodlemobile in that function, I think we need some advice from integrator or core maintainers about the best way to make this file available for translation.

Notice that the mobile.php file is not going to be used inside Moodle, this file will be fetched by the MoodleMobile app using WebServices. We need this file inside Moodle in order to be available in AMOS for other languages translation and for allowing admins to translate/customize the strings used in their app.

Regards

Adding Eloy as watcher for feedback since I don't know who is the maintainer of this component

In order to make available this file for translation we need to add a new subsystem called moodlemobile

We need this file inside Moodle in order to be available in AMOS for other languages translation

That's not exactly like that. AMOS can be used for translating non-core stuff pretty well - as for example all plugins registered via moodle.org/plugins. I would definitely discourage from polluting Moodle core just because we need to get some language pack into AMOS. There are couple of alternative solutions - e.g. publish the plugin in plugins or set-up AMOS so it would track some public Git repository etc.

and for allowing admins to translate/customize the strings used in their app.

Again, not 100% true. If we publish the string file as a part of a local plugin, it could be locally customized without the need to modify the core. And not hacking the core has been perceived as a better solution for this sort of things. It took us while to get rid of things like moodle.org.php components in the core. Please, let's try not to re-introduce them again.

Hi David,

thanks for your comments, if is not fair add anything in core the only way then is:

You want this cool feature of Moodle Mobile, you need to install an additional local plugin with extra functionallities

I need to ask Martin because currently for using Moodle Mobile you don't need to install additional plugins at the Moodle side

Regards

Adding Martin as watcher, I think we need his opinion

Ah, then I think I misunderstood the sentence "Notice that the mobile.php file is not going to be used inside Moodle, this file will be fetched by the MoodleMobile app using WebServices". I thought that the strings file would be fetched from some central repository, not from the connected site itself. It's different situation then. Sorry for the noise.

I removed the issue from peer-review as it was assigned to Helen and she did review it.

Juan, try to make a subsystem and send it for integration. Then if the subsystem solution is view as a bad idea (or if you don't like it), then a good alternative is to make an even simpler format (maybe a json). At the end the file doesn't have much to do with Moodle site itself. Then let the client download the file or return the json string in get_siteinfo (if the file content is going to become too big make a webservice function for it).

cheers.

Sending for integration review

Notice that previously also a component was added for the moodle.org site translation

Hi guys,

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:

1. Will the mobile client be connecting to a site to get language strings.
2. Will the mobile client be able to connect to multiple sites.
3. 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.
Sam

I don't like the idea of this language file in core, plugin would be so much better. It could be a standard plugin actually (included in standard moodle package). Besides you might want to use it to add some specialised webservices commands there later as well.

Moving this reopened issue out from current integration. Please, re-submit it for integration once ready.

Hi Sam,

thanks for your thoughts and comments

You raised this question:
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.

These features are what I want for the mobile app, actually, this is how it works the app right now, you can drop a mobile.php file in the lang/en folder of your Moodle site and the app will start to synchronize the language strings (the work in the app side is done, we use caches and the user can select the period to synchronize the lang file and also force a language synchronization at any time)

Our plan is to let the user choose a language to be used in the app (adding preloaded language files as Moodle does), if you choose French you will see the app in French, if you connect to a Moodle site only in German you will continue using the app in French, if you switch to German the app will try to synchronize the local german translation with the remote german translation customization if present.

Notice that our plan is not only to allow Moodle admins translate the app to their own language, also allow to customize the language to your needs (replace course by Traning Unit, teacher by learner, etc...)

Regards

So what do you see as the way forward Juan and why?

Well,

I think that we have three options:

1 Add mobile as a new component as suggested. I think that the Mobile app will have more interactions with Moodle in future versions (like the PUSH notifications) so having a mobile component may be reasonable

2 Do not add a new component, because the users at any moment can drop the mobile.php file in the lang/en folder, it seems a little bit "ugly", the disadvantage is that you can't use AMOS or the Moodle lang editor for translating or modifying the file so any further changes requires download, edit and upload manually to lang/xx folder again the file

3 Do not add a new component and add the mobile.php file to AMOS so translators can start working in translating the Mobile app, it will be amazing also if AMOS exports the strings via a public URL in json format for auto sync

If you don't seem reasonable adding a new core component option 3 is a very valid alternative, in my side I can change easily how strings are synchronized

So +1 for 3

Regards

Hi Juan,
if users already drop the mobile.php into the moodle, why not develop a plugin "mobile-app-server" and register it in plugins db? It will go to AMOS automatically, will be easy and straightforward to install (without hacking way of dropping file) and so on.

Hi Marina,

thanks for your comments, I think that this is a policy question.

It is supposed that the official Mobile app should work with all the functionalities without installing additional plugins, this same possibility was raised when talking about the PUSH notification plugin at Moodle side.

In my opinion, having an additional plugin that enhance the mobile app functionalities (beyond the core ones) it's a good idea. But it's not aligned with previous decisions

Not sure if Martin wants to add his thoughts here

Regards

plugin still may be included in standard distribution. But I agree, it's a policy question

I can't see issues with a core string file but if it isn't popular with integrators then I'm fine with a plugin that is distributed with Moodle.

But where would that plugin be? (Tip: don't say local)

Admin tool?

Will it have a UI? Should we move the Mobile settings which are currently under:

Home / Site administration / Plugins / Web services / Mobile

?

Yes, I think that having a UI will be interesting since the plan is add new settings for future functionalities like "Enable PUSH notifications"

So if is ok for all, I will close this issue and create a new one "Create admin_tool for Mobile app settings and language translation"

I don't think that using the AMOS as a provider for these strings is an option. Admins would have no way to locally customize them.

Also, if you decide to actually copy some current strings to a new component (e.g. from moodle.php to tool_mobile.php), let me suggest to use the CPY instruction for AMOS in the commit message so that our good translators do not need to do all the hard work again.

Closing, I've created a new issue for the new admin tool MDL-43118