I haven't seen $mvv(58) before in any CSP application.
So this might be an action for WRC to find out why / where it is lost

Sorry,

I'm not sure this really your problem. It could be. 

The first TEST should be your Mgmt Portal.

Language definitions are predefined and loaded at installation time.
to change it later from Mgmt Portal: 
System > Configuration > Locale Definitions 

If you run on UNICODE it should be enough to change it to PTBW - Portuguese, Brasil, Unicode (comboBox)

ending 8 = 8 bit encoded
ensing W = WIDE = Unicode

If your system is any 8bit installation. Someone else may have an answer. It may cause some troubles on a running installation. I never touched this.

my personal experience in management portal:

changed my primary browser language from  "de"  to "en"  and the portal followed at next browser start.

So this might relate to ZEN somehow:
Do you use the $$$TEXT equivalent of ZEN ? $$$TextJS, $$$FormatText

for details and how-to see http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY…

Does your Caché NLS seting support pt-br  ?  (mine includes German DEUW)

Rodrigo is right:

http://docs.intersystems.com/latest/csp/documatic/%25CSP.Documatic.cls?…

says:

• property Language as %String;

The language (RFC 1766 format) in which pages in this CSP session are to be displayed.
The %session. Language attribute is used as the default language for csp:text, span and div tags if %response.Language is not set. If %session.Language is not set by the program, then it will default to the best fit with the HTTP_ ACCEPT_LANGUAGE CGI variable.

So enable connection in Mgmt Portal

YES, I will.
Take a look to  Athanassios Hatzis' contributions. It sounds like another  New Language project. 

You are right. We were happy writing a whole operating system in Assembly language (VAX/MACRO32) and we found it partially overdone compared to PDP-11/MACRO16. But we knew exactly what every bit in our box did. Not even C could give us that level of control.

I personally think a programming language reaches its limits when only a low percentage of developers still oversee it.
Therefore I think your idea to have a new layer on top of COS is much better as it doesn't impose any limitations that are required for backward compatibility.
So you are free to take with you what seems useful and leave behind old junk.

COS contains a real bad example that causes troubles over and over for beginners:
IF  / ELSE old style manipulating $T   vs.   IF { } ELSE { } new style not touching $T 
and some others

That must no happen again. With a new layer you leave this behind and have all freedom.

I think this should be the way to go: "New language translated  to COS"
And I'm sure it would be better than the ugly attempt to map COS into HTML as done in CSP   

Maks I fully support your position.
There are very few languages where you can run code written  40 yrs. ago with no modification !
That's what counts for customers.

You have other languages in parallel like MV or BASIC besides all the embedded things like &SQL(), &HTML(), &JS()..

But with same reasoning you may ask why is Java, JavaScript  or C, C# not changed?
Because you got GO, Angular, ..... to have attractive extensions.
COS has it's ZZ*, $ZZ* as extensions.  ( ZZ* ! )

Isn't this enough for thousands of developers that haven't asked for it nor have a need  for it?  

$system.SQL.Shell()  is bypassing ODBC Driver and talks directly to Caché Storage
an external query tool expects to get a MAXLEN by definition of ODBC  (ages back).
So this is a matter of backward compatibility.
Pls. check the grey hook left of ANSWER to confirm questions as done

Thx.

pls.  place this in a separate question to make it public to others

for this cases a possible solution could be 

%Stream.Global has a FindAt method that could give you a position of  "\u00"

[Find the first occurrence of target in the stream starting the search at position. ]

http://docs.intersystems.com/latest/csp/documatic/%25CSP.Documatic.cls?…

But: if you are on the decoded stream all non printables are just single characters. No issue to cut it in pieces

• read your source stream in reasonable sized junks
• clean out what ever you need
• append it to a temporary stream
• loop on source until you hit AtEnd condition
• finally replace your source either by "copyFromSteam" method [temp -> source]
  or replace source stream reference by temp stream reference

I guess the whole code is shorter than this description.

I'd suggest not to touch the global under the source steam.

of course it makes sense!

but then you know which application is using it and can use the application's cleaning method / routine that takes care of all kind of dependencies:
I remember well times when routines used to start with  KILL ^CacheTemp*($JOB)
I expected over time most applications are using PPG  (^||myGlobal...) to avoid this. Or have a Clean-Up.

So for a first check if this  is the only issue just throw the full string into a $TRANSLATE
$tr(jsonstring,$c(26)) and whipe it out.

e.g.
ZNAMESPACE "%SYS" 
be careful !