[Question] Language support in ftp and xmlrpc libraries

The ftp and xmlrpc/xmlrpcs libraries encapsulate communication protocols.
The ftp library has a language settings file, while the xmlrpc libraries do not.
Should these be treated the same?

If these are to be treated consistently, it would appear that either the ftp language settings should be eliminated (brought into the Ftp class as English only), or else that we should consider adding a language settings file for the XML-RPC.

Do you use the Ftp library? Are translations appropriate?
Do you use the Xmlrpc libraries? Would translations be appropriate?

Inquiring minds want to know

James Parry
Project Lead

The ftp and xmlrpc/xmlrpcs libraries encapsulate communication protocols.
The ftp library has a language settings file, while the xmlrpc libraries do not.
Should these be treated the same?

If these are to be treated consistently, it would appear that either the ftp language settings should be eliminated (brought into the Ftp class as English only), or else that we should consider adding a language settings file for the XML-RPC.

Do you use the Ftp library? Are translations appropriate?
Do you use the Xmlrpc libraries? Would translations be appropriate?

Inquiring minds want to know

Should these be treated the same?

Absolutly yes!

No, I am not using the FTP library, but I think it should provide translations and yes, they are appropriate.

Yes I am using XMLRPC, but only for automated tasks without showing any error message to the users. If something bad occurs I make a new log entry with the error message. I think we should be consistent and provide translations to the Xmlrpc library too.

Now here is 1 small note -
FTP translations are all related to problems / fails and in many cases those messages are only used for debug/development or by Administrators to detect problems. In most of the cases this information doesn't goes to public clients of the app. This generates the question - why we have translations there?
( BTW its really strange some times to read some technical error translated to Bulgarian , as some of the things are not translatable and its a mix between BG and EN )

Keeping the logic of CI there should be another translation for xmlrpc.
When there is a problem there should be and info about it.

Best VPS Hosting : Digital Ocean

Since I don't really use these libraries (now that I said it, though, I'll probably have some big project that requires both of them) and English is my first language, it doesn't really make a significant difference to me.

The actual error message only matters to me if I immediately know what's wrong. Otherwise, I just search the code for the text of the message and read the code to try to figure out what went wrong.

I tend to think that anything which can be translated should be. It makes sense that there would be limited or no translation support in areas which are enabled and running before the Lang class is loaded, or under conditions in which you might assume that something went so horribly wrong that you can't rely on the application state. I do think developers appreciate messages in their native language, when possible, and that the distinction between an error displayed to developers and one displayed to end users is sometimes blurred when the developer finds the message adequate for at least a portion of the message passed along to the end user.

Besides, the ftp library's use of lang->line() is piped to show_error(), which is going to end up in the end user's face unless the developer takes significant steps to prevent it.

Bonfire

Practical CodeIgniter 3
CodeIgniter Testing Guide