SIM Card Type: VIVO SW Version: D300fAT-00-V07a-BRA-VIVO-MAY-03-2013+0 Test Place: Sao Paulo , BRAZIL Owner Issue: Thais Souza da Silva - SP / Brisa FT CheckList: Global CL Test Item: 516 Occurence Frequency: 100% - 10 Fails in 10 Tries Pre Condition: DESCRIPTION: Configuracoes > Vivo chip > Mensagens > Caixa Postal > Ouvir Recados Check the message shown EXPECTED: The handset should show the message in the correct language. (Portuguese) ACTUAL: The handset shows the message in English. --------------------------------------------------------------------------------------- When user take a test for setup-call in android and firefox(d300) model by using VIVO operator sim card, displayed language is different. plz confirm attached video clip. <icc.js> function handleSTKCommand(command) { ... case icc.STK_CMD_SET_UP_CALL: debug(' STK:Setup Phone Call. Number: ' + options.address); if (!options.confirmMessage) { options.confirmMessage = _( 'operatorService-confirmCall-defaultmessage', { 'number': options.address }); } ... } --> 'operatorService-confirmCall-defaultmessage' value is only defined for US language. However, android model is defined about each language. we would like to know whether this is normal operation or not.

Hi Carol, In 831627 Languange selection is implemented in Reference RIL. Is it supported in Commercial one?

Screenshots of a simulated SET_UP_CALL proactive command in both English and Portuguese.

Fernando, Language selection is implemented in Commercial RIL on v1.1. However, AFAIK, the issue reported by this bug isn't about that. From bug 847043, you added a default message to display 'Call {{number}}' whenever the alphaId is empty for a SET_UP_CALL proactive command. In this case, the default message is defined by 'operatorService-confirmCall-defaultmessage' from the settings.properties file. I just checked and I do see this same message being defined in settings.properties files for other languages, including Portuguese. Leo, I've simulated a SET_UP_CALL with empty alphaId (in both English and Portuguese) and do see them displayed in the chosen language. Please see attachment 759426 [details]. Have you exported all the proper environment variables for a multilocale build? Please refer to https://www.codeaurora.org/xwiki/bin/FirefoxOS/WebHome on how to do that.

(In reply to Carol Yang [:cyang] from comment #4) > Fernando, > > Language selection is implemented in Commercial RIL on v1.1. However, AFAIK, > the issue reported by this bug isn't about that. > > From bug 847043, you added a default message to display 'Call {{number}}' > whenever the alphaId is empty for a SET_UP_CALL proactive command. In this > case, the default message is defined by > 'operatorService-confirmCall-defaultmessage' from the settings.properties > file. I just checked and I do see this same message being defined in > settings.properties files for other languages, including Portuguese. > > > Leo, > > I've simulated a SET_UP_CALL with empty alphaId (in both English and > Portuguese) and do see them displayed in the chosen language. Please see > attachment 759426 [details]. > > Have you exported all the proper environment variables for a multilocale > build? Please refer to > https://www.codeaurora.org/xwiki/bin/FirefoxOS/WebHome on how to do that. Dear, Fernando When I have confirmed operatorService-confirmCall-defaultmessage from settings.properties, it is defined only settings.en-US.properties file. Therefore, as you said that, I already fixed prblem which cannot display Portuguese language by adding "operatorService-confirmCall-defaultmessage=Chamar {{number}}?". but, I think that it needs to add code for other language. when I have checked the code, it is not defined.(settings.fr.properties, settings.zh-TW.properties, settings.ar.properties) thank you.

Since this is a localization issue, I'll move it to the correct team.

The in-repository translations are not maintained. pt-BR in general has 200 missing strings for 1.1, and these message don't even show up on the radar. I suspect they've been added in the last few days. We're not even remotely close to being done with localizations to start talking about individual strings. Resolving INCOMPLETE, this will not be dealt with on a individual bug level.