You can create a report rule to do this. As per the below screen shot,

1. create a new report rule
2. Select your report for Report ID
3. Add a new condition and set Expression 1 to [#CurrentUser] or [#PrintedBy] - use RMB → Edit Expression 1 to easily edit this
4. Choose operator as =
5. Set Expression 2 to your user’s ID
6. Add new action - Set property will force this - user can’t change it anymore. Or use Preselect property which will selects the locale language but allows user to change if required
7. RMB → Edit action properties → Set the local language you wanted

Thanks @Rusiru but this only changes the language, what i want to do is change the number/date format, which is not connected to the language, i.e, in both cases the language is EN, but the formatting is en-AU and en-US. 

LangCode property sets the language. 

Number/Date format is set by LocaleLanguage and LocaleCountry. 

Try setting all the 3 properties below. 

Set LangCode as en, LocaleLanguage as en and Locale Country as you want. For the LocaleCountry, I don’t see “AU” in my list, but i think you should have it in your environment.

Hi @Rusiru, thanks for that, although i did not have AU in the list i can type AU in and it does change it on the report when printing so it does achieve the desired result. 

However surely you’d want this to apply to all reports for all users of a specific region. When you do not specify a report name in the rule and leave it blank the system warns about potential performance impact. Is this an issue?

Also, this means i’d have to create a specific rule for all of the users affected, (250+), there must be a better way to do this without a rule?

As I understand your requirement, i don’t there there is a better option to do this other than report rules. 

Regarding performance: it depends. If you keep report id blank, this rule will evaluate for all prints. If your condition is not too complex, i don’t think it will be a big problem. But report rules provides functionality to support SQL queries written inline in conditions and actions. So if you write large SQL queries for the evaluation, it will have an impact. 

Regarding multiple users: There are other parameters that you can setup the condition. There are some generic variable and Xpath variables based on the report. If you can filter based on a pattern that all want to print in “AU” using any of the given variables or Xpath values, one or several report rule should be enough. Again you can use SQL queries if needed - see technical documentation path .../040_administration/250_operational_reporting/070_report_rules/default.htm for more instructions.