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?P...

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.

if you open BPL in Studio click here to switch to Class view

by program the code is found in class %Dictionary.XDataDefinition

Property Data holds your XData as Stream

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

to find the id you can use
select ID from %Dictionary.XDataDefinition where parent %startswith '<my class name>'

The default for %String is MAXLEN=50

if you write in your definition %String(MAXLEN="")   also in Method calls this should be enough.

Query Methode(data1 As %Library.String(MAXLEN=""), data2 As %Library.String(MAXLEN=""), data3 As %Library.String(MAXLEN="")) As %Library.Query(CONTAINID = 1, ROWSPEC = "Result,Par2:%String") [ SqlProc ]

  and so on.

Or you make you own data type  inheriting %String overwriting  Parameter MAXLEN=""

Or just use %Library.VarString which makes just this MAXLEN=""
http://docs.intersystems.com/latest/csp/documatic/%25CSP.Documatic.cls?P...

Query Methode(data1 As %LibraryVar.String, data2 As %Library.VarString, data3 As %Library.VarString) As %Library.Query(CONTAINID = 1, ROWSPEC = "Result,Par2:%VarString") [ SqlProc ]

  and so on.

It's possible but counter productive
since: if you switch off journal this get's logged in Audit and generates at least 1 entry in journal
and swicthing it back on for the rest of your application you get another entry.

I just don't recommend things with negative impact on performance. 

Anyhow IF you insist it's your fate:

http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=...

You may do it as well with SQL

select count(*) cnt , ID from (
  select 'PERS' Typ, ID from %Dictionary.ClassDefinition
  where Super [ 'Persistent'
    union all
  select 'XML' Typ, ID from %Dictionary.ClassDefinition
  where Super [ 'XML.Adaptor'
)
group by ID
order by cnt desc

Result : 2  both classes contained  in class

cntID
2%BI.Blog
2%BI.BlogPost
2%BI.DashBoard
2%BI.DetailList
2%BI.DocMag
2%BI.ImageList
2%BI.KPI
2%BI.ListField
2%BI.Measure
2%BI.PerfMet
2%BI.PerfMetNode
2%BI.PivotData
2%BI.PivotTable

Dashboards are always fresh calculated.

Compare the performance in .NET  to  IE.  It should be rather close to each other being based on similar technology.

If there is a significant difference then you dig at  .NET end (buffers, ...)

If Chrome is significant faster then IE it's most likely the faster JS engine in Chrome.

Next you could look into global buffers of Caché and concurrent use of the Caché instance.
And (rarely) the complexity of your dashboard