[opensource-dev] someone get the blindfold off me please - where in the sourcecode is the spot where a "parcel full" message is created?

[Henri Beauchamp]

On Wed, 06 Aug 2014 17:49:24 +0200, Lance Corrimal wrote:

> Am Dienstag, 5. August 2014, 16:11:11 schrieb Darien Caldwell:
> > I'd suspect that the viewer simply makes a rez request to the Server, and
> > the server makes the determination it can't be completed, and why. LIkely
> > the server just sends back the error message via some sort of generic
> > callback. In short the message wouldn't be in the viewer. I may be wrong
> > though.
> 
> 
> That's exactly my problem here, I see a "missing string" error in my logfiles, 
> but I can't find the missing string in the original strings.xml or 
> notifications.xml of the development viewer... And I can't find the creation 
> of the message itself, either, but in the original viewer i do get a "parcel 
> full" error at the appropriate moment.
> 
> I frankly do not know where to look 0.o
> 
> Help!

Look inside indra/newview/llviewermessage.cpp, process_alert_core() function.
My *guess* (not having this problem, here, with v1-style notifications), is
that you reach one of the
std::string new_msg = LLNotifications::instance().getGlobalString(message);
lines in that function, and there's no corresponding "global string" for
that particular message, so the translation fails... Which is not surprising,
because many server-side initiated messages don't have a template in
notifications.xml neither any translation string in strings.xml.

The v1 viewers were not attempting to translate such messages at all cost,
so they just display them in plain English and without error.

I suppose you could add a method in LLTrans that would allow you to check
for the existence of a given string before actually calling
LLTrans::findString (which errors out when the translation does not
exist). If the translation doesn't exist, then just display the message
"as is".

To confirm my diagnosis, just put a few llinfos in process_alert_core() and
see what happens...

Henri.