Is it possible to configure the gateway prompts, as returned by JEP-100 stanza of the form:
Becuase at present, for say Yahoo, the prompt returned is:
“Please enter the YAHOO username of the person you want to add”
This doesn’'t seem very good, surely “…the person you want to contact” would be better.
Anyway, be good if this was configurable?
Hrm, I mean, I -could- certainly add functionality to let folk change the prompts, but wouldn’'t it be better if I got the wording rewritten better? Can you think of a reason why it should be configurable if we just fix up the wording? What would your suggested wording be?
Well assuming the prompt is the prompt used for the person to enter an external ID to send an IM to that ID then something like (for yahoo) - “Please enter the YAHOO username of the person you want to contact”
However, this is english specific, these prompts should be configurable so admins can set them for the local language.
camclive wrote:
However, this is english specific, these prompts should be configurable so admins can set them for the local language.
Note that you have to specify the correct xml:lang-attribute when using a specific language (this should be true for English as well, but unfortunately isn’'t done most of the time). That way you can also specify the message in multiple languages at the same time.
True that particular message is english specific, but all of the strings in the plugin are localized (and if they aren’‘t I need to fix that ones that aren’'t) so basically ideally the entire list of localized strings should be translated to your native local language and submitted back to me so that I can include them in the actual plugin releases. Then it benefits everyone! =) Would you be interested in translating?
The english file is here
The only partial translation I have right now is for german. I’'d certainly love to see more translations coming in!!!
I had almost forgotten about xml:lang. I actually implement using that in the Py transports (well to be more accurate, James Bunton implemented it and I pulled it over to my two transports). That said, I’'ve created GATE-162 to remind me to look into this for the plugin as well.
The point for me is that the prompts used should be referenced in an XML or properties startup file so we can set them to our own particular needs.
You say the prompts are localised - so is there already a properties file we can change?
I really do not want to keep providing workaround properties for every little thing the plugin does. “To what end”. Next thing I’‘m going to hear is someone wanting to be able to set -all- of the text exactly how they want. This is why I’‘m asking questions and being rather resistant to this. The more stuff that becomes configurable like that, the harder it will be for me to debug things. If someone comes and says “I got a prompt that said ninja monkies, what does that mean?” to me, then what am I supposed to say? I have no idea. At some level I’‘d like to know what you would be putting in that field instead of what’‘s already there if you don’'t mind telling me.
Sure you can mod the properties, but things like this are going to make me have to add a “if you modify this I can’'t provide support” clause. =) It’'s hard enough to debug my -own- stuff. lol
Having the core gateway prompts for JEP-100 configurable seems a reasonable suggestion to me. The core functionality seems to be pretty much there with the properties files you have.
My original suggestions for alternative english prompts and questions about their meaning are in the first posts of this thread.
Given the existing properties files. All I am asking is that the prompt returned by the JEP-100 request for each gateway is added to the properties files.
People can change these anyway for their local use of the gateway and you can keep a central resource of strandard ones for each language.
It is more like a bug that a german user has german prompts returned for most of the gateway usage but would have hardwired english prompts returned for the JEP-100 request?
Message was edited by: camclive
? It … is? For example from YahooTransport.java:
return LocaleUtils.getLocalizedString(“gateway.yahoo.registration”, “gateway”);
And in gateway_i18n.properties:
gateway.yahoo.registration=Please enter your Yahoo! ID and password.
People can change these anyway for their local use of the gateway and you can keep a central resource of strandard ones for each language.
It is more like a bug that a german user has german prompts returned for most of the gateway usage but would have hardwired english prompts returned for the JEP-100 request?
I don’'t really understand where the ''hardwired JEP-100 requests" are coming from that you are referring to. I hardwire very little english nowdays except for the debug messages.
That said, note that some clients that I glare at don’'t bother actually really performing the JEP-100 request and just print out whatever they feel like printing out.
Daniel
camclive wrote:
Message was edited by: camclive
Having the core gateway prompts for JEP-100 configurable seems a reasonable suggestion to me. The core functionality seems to be pretty much there with the properties files you have.
My original suggestions for alternative english prompts and questions about their meaning are in the first posts of this thread.
Given the existing properties files. All I am asking is that the prompt returned by the JEP-100 request for each gateway is added to the properties files.
I think we are going round in circles here.
Can you clarify where the prompt is specified which is returned for the IQ request:
I can’'t find the latest source but the one that comes with wildfire 3_1_1 seems to have this prompt hardwired in the code at handleIQGateway in BaseTransport.java:
query.addElement(“desc”).addText(“Please enter the person’'s “this.getName()” username.”);
Maybe this has changed in the latest version?
That is correct, it is now:
query.addElement(“desc”).addText(LocaleUtils.getLocalizedString(“gateway.base.e nterusername”, “gateway”, Arrays.asList(transportType.toString().toUpperCase())));
The gateway plugin doesn’‘t follow the same release schedule as wildfire. (I’‘m actually a little suprised to hear it’'s included in the source build, might chat with the Jive folk about that)