Translate Like a Pro | 9800 — Microsoft sqlcmd Localization, -v Variables, Go and ODBC Options, Unicode Files and Batch QA

Microsoft sqlcmd lets people run Transact-SQL scripts from a command line, a job or an interactive session. In an international organization, the same script may be operated by people who speak different languages and open its results in different software. The challenge is to translate human-facing guidance, report labels and operational errors without silently changing the database connection, SQL script, query results or security controls.

This guide explains how to localize Microsoft sqlcmd usage instructions, -v scripting variables, :Setvar expressions, input files with -i, output with -o, Unicode with -u, code-page settings with -f, and failure handling in batch automation. It also distinguishes sqlcmd (Go) from sqlcmd (ODBC), because these variants do not implement every flag and locale-related behavior identically. If you are searching for sqlcmd Unicode output, translated SQL Server CLI help or multilingual batch-report QA, those distinctions come first.

We begin with a harmless read-only SQL demonstration, explore the difference between sqlcmd client commands and Transact-SQL, and then follow a report through variables, encoding, errors and final export. The intended reader might be a developer, analyst, translator or operations engineer anywhere in the world. The aim is precise, understandable guidance that preserves what the program actually does.

Quick answer

Keep sqlcmd flags, commands, scripting-variable names and SQL syntax exactly as the installed tool expects.
Translate explanations, reader-facing messages and report labels, but do not turn translated prose into unvalidated SQL.
Identify whether sqlcmd (Go) or sqlcmd (ODBC) is installed before documenting -R, -f, -r, -u or other options.
Treat output encoding, terminal rendering, locale-based formatting and Unicode fonts as different tests.
Compare query results, exit status and batch behavior against a known baseline before releasing localized documentation.

A safe read-only demonstration

On an authorized training SQL Server connection, a minimal input file can contain the following read-only batch. No table, schema, user or permission is changed. The snippet is not a connection recipe: credentials and server configuration must follow your organization’s secure setup, and output files should use disposable locations.

SELECT N'Example multilingual report' AS report_title;
GO

The N-prefixed literal is a Unicode string expression for the demonstration. Run the script only against an approved server, inspect the terminal output, then separately test output redirection with a scratch filename. To demonstrate scripting variables, read Microsoft’s documentation for -v and :Setvar before modifying an existing query. A working string substitution is not proof that arbitrary input has been validated or safely parameterized.

Understand the two sqlcmd interfaces

sqlcmd (Go) and sqlcmd (ODBC) are distinct

Microsoft documents two variants of sqlcmd: a Go-based utility and an ODBC-based utility. Both can provide familiar SQL Server workflows, but some flags and compatibility behaviors differ. A translated guide that promises one universal command form can mislead a user who has installed the other variant.

An operations engineer may copy a line using -R from older ODBC-oriented instructions and expect locale formatting in the Go variant. Microsoft states that -R is ignored by sqlcmd (Go).

Identify the actual installed utility and version first, then document supported flags for that exact environment. Treat variant detection as a release prerequisite.

The Go variant has more than one help mode

sqlcmd (Go) includes modern commands and compatible flags, with help modes that serve different usage paths. Translating a screenshot of one help page as though it covers every possible invocation may omit crucial options or introduce unsupported syntax.

Show the appropriate help invocation for the reader’s installed version and explain which part covers modern commands versus compatible switches. Leave the option spellings unchanged.

Review the displayed help on a real installation rather than relying on a remembered list from a different machine. Avoid claims about flags that the version lacks.

Options belong to the command line

Flags such as -i, -o and -v are parsed by sqlcmd, not by a natural-language translator. They determine input file, output destination and scripting variables. A localized explanation can describe each flag clearly, while the literal flag remains the same.

If an editor changes ‘-o’ to a translated word meaning ‘output’, the operating system will not reinterpret that word as the correct switch. The documentation has become nonfunctional.

Protect command lines in code blocks, and have a reviewer run only non-destructive examples. Preserve hyphens, spacing and case-sensitive argument values where required.

sqlcmd commands are not Transact-SQL

The sqlcmd utility has commands such as :Setvar, :r and :Out in addition to SQL statements that a database server executes. Most sqlcmd commands begin with a colon and are processed by the client. Treating their syntax as SQL or translating their names can break a script before it reaches the server.

Suppose an article explains :Setvar in another language. The translated explanation must not replace :Setvar in the executable sample, and the reader must know that its effect is client-side.

Annotate each example with its layer: shell, sqlcmd client or T-SQL server. This is more useful than translating every unfamiliar token.

GO terminates a batch

GO is a batch separator understood by SQL utilities, not an ordinary English verb in a running paragraph. It tells sqlcmd when to send accumulated statements for execution. Moving or removing it can change execution order, variable scope and error behavior.

An editor may format a code listing and accidentally merge GO onto the preceding line. The result may be rejected or behave differently from the approved script.

Keep batch delimiters on appropriate lines and include them in regression checks. Treat layout changes in executable snippets as functional edits.

-i supplies a script file

The -i option identifies input script files. Documentation should explain whether the path is relative, how the shell handles spaces and which encoding the installed tool expects. Translation of nearby prose does not authorize translating actual directory names or file extensions.

A colleague pastes a file path with a space but omits required quoting for their shell. The resulting error is a launch problem, not a failure of the SQL logic.

Test with a harmless local input file on the target operating system. Avoid implying a Windows launch line is universally portable to other shells.

-o directs output to a file

Using -o writes output to a named file. Microsoft documents behavior that can create or overwrite files, so even a read-only SELECT may have a file-system side effect. A tutorial should use a disposable output path and warn operators not to select a valuable existing report.

Imagine a translated handover note that changes the output filename without changing a dependent automation. The job may run but downstream readers will not receive the file they expect.

Keep machine-facing paths stable unless deployment configuration explicitly changes them. Confirm the actual file after execution and protect existing artifacts.

-v supplies scripting variables

The -v flag can pass named sqlcmd scripting variables at invocation. Such variables are not automatically translated user messages, and textual substitution can interact with SQL syntax. Machine-readable names should remain stable, with descriptions localized separately.

A script might expect a variable named ReportLanguage to contain en or fr. Translating its name in one place but not another can cause an undefined-variable error.

Use a documented whitelist of permitted values and avoid passing unrestricted user input into a query template. Verify the final script behavior rather than trusting the friendly prompt.

Understand :Setvar inside a script

:Setvar defines a scripting variable whose references appear as $(VARNAME). Microsoft documents rules for naming, value quoting and precedence. This is a client-side substitution mechanism, not equivalent to a typed SQL parameter. Its purpose should be explicit in a multilingual manual.

A harmless example can use a stable language key for display. An unsafe pattern would substitute an arbitrary human-entered SQL clause into a query.

Review each variable’s intended context and validate values before use. Do not equate successful substitution with safety or semantic correctness.

List and environment variables need care

The sqlcmd client can receive scripting-variable values from the environment as well as explicit definitions. Precedence matters, and the -X option can prevent environment variables from being passed. This behavior is operational, not something translation changes.

An automation job inherits a value from its host and produces a different report than a developer’s interactive run. A localized message may not reveal the hidden source of the value.

Test the actual job environment, document configuration ownership and avoid copying private environment-variable values into shared screenshots or logs.

Translate help without changing executable meaning

A good help line specifies the action

‘Output file’ is clearer when a user knows that the named file may be created or replaced. An international guide should describe the consequence of each relevant switch, not merely provide a dictionary translation. Precise verbs help operators avoid unintended file changes.

Compare ‘save output’ with ‘write query results to this path; an existing file may be overwritten’. The second communicates an action and a risk.

Review every translated option description for side effects, defaults and important exceptions. The goal is a correct operational decision, not the shortest wording.

Localize error explanations, not error identity

An error message can contain a stable SQL Server code, severity or return status alongside a natural-language explanation. Translation should preserve the diagnostic identity and any instruction about stopping a job. Otherwise an operator may mistake a failed export for a successful one.

Document a fictitious input-file-not-found case with the observed error category and a concise remedy, without inventing an official server error number.

Have support staff confirm they can still search for the stable code and reproduce the issue. Never replace a diagnostic with a vague courtesy sentence.

Preserve the difference between warning and failure

Batch jobs may log informational messages, warnings, SQL errors or failures before a connection is established. Translators must not soften mandatory stops or imply success when a script never reached the server. Likewise, a warning should not be automatically rewritten as a fatal error.

An export may finish with a caution about truncation. A reader needs to know whether the file is usable and what verification remains.

Review severity, exit behavior and next action together, using test results from the actual sqlcmd variant. Friendly tone cannot substitute for accurate status.

Describe -b in the context of automation

The -b option can affect batch-job error handling. A translated manual should explain how the chosen error threshold and sqlcmd behavior are expected to surface to the surrounding scheduler. A successful-looking console transcript is not proof of a zero failure rate.

Use a controlled test that deliberately produces a harmless SQL error against a non-production server and inspect the process exit status. Do not test by changing live data.

Record the utility variant and options used. Preserve the distinction between the program’s diagnostic message and the operating system’s reported process status.

Explain :On Error accurately

sqlcmd supports client-side :On Error choices such as exit or ignore. These are executable instructions affecting control flow. Their natural-language explanations need to preserve the consequences: continuing after an error can lead to later output being generated without earlier prerequisites.

A translation that calls ignore ‘repair’ would be seriously misleading. The command does not automatically correct the failed statement.

Review which scripts may safely continue and which must stop. Treat a change in :On Error as code maintenance requiring testing, not a wording improvement.

Do not translate variable keys

Variables such as $(ReportLanguage) are literal references used by the client. Replacing the name with a translated phrase in documentation can make copied examples fail. A better multilingual interface explains the key once and lets the surrounding prose use the target language.

Provide a tiny vocabulary table: stable key, accepted values, friendly description and usage example. An operator can learn the grammar without guessing.

Test the copied example line by line. If a reader has to reverse-translate a variable name before running it, the documentation has failed.

Localize user messages outside query structure

A SQL Server script may SELECT a constant string as a visible report title or obtain a label from a reviewed lookup table. Translation belongs in these presentation strings. Changing WHERE clauses or JOIN conditions to get a translated title can change row selection.

Imagine a report returning the same invoice totals with an English or Japanese heading. The underlying predicate and grouping must not change merely because the heading does.

Compare stable row identifiers and numerical aggregates across language versions. Keep display text separate from the query wherever practical.

Avoid secret values in command examples

Passwords and connection details may be exposed through command histories, process listings or shared logs when placed directly on a command line. Teaching localized help must not encourage readers to paste real credentials into a public example. Microsoft offers different authentication methods depending on environment.

Use placeholders for servers and training accounts, and explain that the actual authentication design belongs to the organization’s security policy.

Do not publish a production connection string or screenshot containing credentials. Review the visibility of environment variables and error logs as well.

Connection settings are not a language setting

Server name, database, authentication mode, encryption settings and certificate validation affect where and how the client connects. Translating a connection error should not lead an operator to disable verification or change servers just to make the workflow finish.

A local-language guide can explain -S and security options without changing their behavior. A certificate error is a security diagnostic, not a spelling problem.

Keep secure connection configuration under the responsible administrator’s control. If a translated instruction proposes a trust change, require separate security review.

Line breaks can alter script behavior

sqlcmd commands have line-position requirements, and Microsoft documents that commands execute separately from SQL statement buffers. A translation editor may wrap lines for readability, causing the client to interpret a command differently or reject it.

Do not let a publishing template insert a line break inside :Setvar syntax or merge a command with SQL on the same line. What is fine in prose may be invalid in a script.

Maintain copy-tested code blocks and compare them after publishing. The blog renderer is part of documentation QA when readers copy commands.

Make Unicode and numeric reports reliable

-u is about output encoding, not translation

The -u flag is documented for Unicode output files. Microsoft’s sqlcmd documentation notes that the Go variant writes a UTF-16 little-endian byte-order mark with Unicode output. This affects how a receiving application recognizes the file, but it does not translate English content into another language.

Create a scratch output file containing a multilingual test string, then inspect its encoding in a trustworthy tool. Compare the visible result after opening it in the intended viewer.

Do not claim that the presence of a byte-order mark proves the words are correct or that every script font can render them.

-f and code pages require precision

Code-page flags determine how particular versions of sqlcmd interpret input and output text. The supported forms and platform details should be taken from the installed utility’s documentation, not from a generic Windows-only recipe. A wrong code page can corrupt data silently.

Use a sample containing an accented name, a CJK string and punctuation. Observe what survives input, query execution and output under the documented code-page settings.

Record the exact environment and compare actual encoded files. Avoid choosing a code page by guessing the reader’s nationality.

Console output and file output differ

The console may use one encoding or font while an output file uses another. The same query can look readable on one terminal and garbled in a report opened elsewhere. A localization test that inspects only the terminal can therefore miss a real release defect.

Run the same read-only query to a scratch file and to the terminal. Open the file in the downstream tool and compare characters, delimiters and line breaks.

Document which destination is authoritative for the project. Fix the encoding boundary rather than replacing accented characters with approximate ASCII spellings.

-R has a variant-dependent meaning

Microsoft describes -R regional formatting behavior for sqlcmd (ODBC), while sqlcmd (Go) ignores the flag. A translated guide that recommends -R without identifying the variant can create false expectations about dates, numbers and currency.

Imagine a multilingual finance report whose authors expect local separators because a flag is present. The Go job may not apply the same formatting.

Check the real variant and output. For machine-readable exports, prefer a documented invariant representation rather than assuming client regional formatting is suitable.

Dates should be unambiguous at the data layer

A displayed date such as 03/04/2026 is ambiguous across countries. SQL Server stores and processes typed dates, but presentation strings can use different conventions. Translating the nearby heading does not solve the ambiguity and should not change filtering logic.

Use a typed value or a clearly documented ISO-style representation for machine comparisons, then render a target-language date display for human readers where required.

Compare row selection windows and sort order across language variants. A report’s date label must never imply a different reporting period from the query.

Decimal separators are presentation choices

Numbers may be represented with different decimal and grouping punctuation in different countries. If a localized report displays an amount differently, the underlying numeric value must remain the same. Exporting formatted text into an automated consumer can produce parsing failures.

Take the numeric value 1234.5 and display it under two agreed presentation conventions. Explain the unit and currency when relevant.

Keep numerical data as typed values until a controlled display step. Document delimiters, decimal rules and rounding for every machine-readable output.

Currency names are not currency conversion

A dollar sign or translated currency name does not identify the exact currency or exchange rate. A report can localize its caption without changing USD into SGD or any other monetary unit. Conversion requires a separately documented calculation and source of rates.

Show an unambiguous currency code beside fictional amounts in an international report. If the business changes the unit, that is no longer a translation-only change.

Review monetary units and rounding with the subject-matter owner. Compare values across editions before signing off.

Fixed-width tables need visual review

sqlcmd output can be formatted with separators, widths and headers. A longer translated column heading may wrap or be truncated, and combining marks may occupy unexpected display width in a terminal. A row that looks aligned in English may not remain readable in another script.

Test the longest approved translated heading and one wide CJK or right-to-left string. Inspect exported text in a monospaced viewer and in any later spreadsheet.

Do not shorten a critical qualifier or unit only for alignment. Adjust the presentation format or document an alternative export.

Embedded separators can break downstream files

If the output separator is a comma, translated text containing commas may be interpreted as additional columns by simplistic parsers. Changing to another separator can cause similar problems when values contain that character. A plain text table is not necessarily a well-formed CSV file.

Use a synthetic label with a comma, quotation mark and line break. Verify that the receiving parser can recover the original fields without altering meaning.

For serious structured exports, choose a format and producer with explicit escaping rules rather than relying only on a pretty terminal separator.

Right-to-left scripts expose rendering differences

Hebrew and Arabic text can appear alongside left-to-right database identifiers, digits and punctuation. Correct UTF-16 bytes alone do not guarantee that the terminal or PDF viewer presents the reading order clearly. Bidirectional rendering needs a final visual check.

Preview a sentence containing an Arabic label and a numeric row identifier in the exact target file. Observe brackets, signs and adjacent punctuation.

Ask a fluent reviewer to inspect the result. Store the proof alongside the release test, and distinguish visual layout defects from encoding errors.

Preserve leading zeros in identifiers

Client-facing codes such as 0012 or 000045 are often identifiers rather than quantities. If a translation workflow treats them as numbers and drops leading zeros, it may destroy their relationship to a source system. A report can be mathematically correct yet operationally unusable.

Show a fictional project code with leading zeros and a separate numeric total. Teach readers which field is an identifier and which is a measure.

Compare identity fields as strings and numeric measures as numbers. Do not rely on a spreadsheet’s automatic type inference when validating exported files.

Test long strings and Unicode normalization

A translated message may be longer than its English source, and visually identical Unicode strings can differ in encoding form. Long labels may be clipped, while accents may be transformed during copy or export. Both can affect exact comparisons and readability.

Use a long German sentence, a word with combining accents and a CJK phrase as test fixtures. Check the source, sqlcmd output and receiving application.

Document any normalization policy for searchable identifiers; do not silently normalize legal names or user-entered evidence as though they were headings.

Release, audit and support across languages

Freeze a known-good query first

Localization needs a baseline. Run a read-only script against a synthetic database or approved fixture and record row counts, stable keys, numeric aggregates, error status and expected output. These become the reference points against which translated versions can be checked.

Without a baseline, a changed connection target or dataset refresh could be confused with the impact of changing displayed language. A plausible report is not proof of equivalence.

Compare results programmatically and inspect wording manually. Keep the test environment and SQL script version in the release record.

Build a safe matrix of accepted values

Each scripting variable needs a contract: name, expected type, allowed values, default, invalid-input response and owner. If a field selects a language, prefer an approved short code rather than arbitrary natural-language descriptions or unsupported locale strings.

Test valid en and fr keys, an unknown key, an empty value and a value containing spaces if the contract permits them.

Record the observed behavior. A script that unexpectedly substitutes an empty value into SQL should be corrected before its translated instructions are published.

Include deliberate failures in QA

A complete test suite must confirm that invalid input produces an honest failure state, not just that valid input succeeds. This includes missing files, unsupported settings and safe SQL errors on a training server. Batch systems depend on predictable exit signals.

Use a disposable input path that does not exist, then record the utility’s diagnostic and status. Repeat with a harmless syntax error in a sandbox if approved.

Do not validate failures by modifying live data. Compare technical status and translated explanation separately.

Test redirection and output-file behavior

The -o option and :Out redirection can affect where output goes. An existing file may be truncated; translated documentation must warn about that side effect instead of implying every execution appends a new report. This is particularly important in recurring jobs.

Use a unique scratch filename and run the test twice to understand the effect. The same SQL results should be checked against file size and content expectations.

Make output ownership, retention and overwrite policy explicit for the production workflow. Protect historical audit files from accidental replacement.

Verify stderr and stdout routing

Automation often treats standard output and standard error differently. sqlcmd has options and commands affecting how messages are routed, and behavior can depend on the utility variant. Translating error text must not accidentally change the channel or make a job monitor overlook it.

Run a controlled diagnostic and observe which stream receives it. Verify that the monitoring system catches the event with the intended severity.

Document the flag combinations and environment. A successful on-screen message is not necessarily the same as a successful monitored job.

Check scripting-variable precedence

Variables may come from command-line options, :Setvar or environment configuration, and the client has documented precedence rules. A team can have identical SQL code but receive different results because a different value wins during substitution.

Set a controlled value through one source, then deliberately provide a second value through another in a training session. Observe and document precedence without using credentials.

Keep one authoritative source for each production variable where possible. Language editions must not silently change which configuration takes priority.

Treat :r includes as code dependencies

The :r command includes additional script content from a file. A translation editor may regard the referenced filename as a human label, but it is a dependency path. Changing it alters which commands run and can change query results.

Create a harmless included script file in a sandbox, then test the invoking command. A renamed directory requires a deliberate deployment change, not a prose translation.

Record included-file versions alongside the main script and review the content boundaries. A top-level script alone may not show the entire execution behavior.

Keep machine labels stable across languages

Report identifiers, environment names, error codes, scripting-variable keys and database object names may be used by other programs. Translating these can break search, reconciliation or downstream automation. Their meanings can be explained in any language while the keys remain fixed.

Publish a table distinguishing stable key, allowed values and natural-language description. A Japanese guide may show the same token ReportLanguage as the English guide.

Ask operators to copy the sample exactly. A document that requires reversing machine-key translations imposes unnecessary error risk.

Review confidentiality and small-cell risks

Even a read-only query can reveal confidential information. Localization teams do not automatically need direct access to personal records, customer identifiers or detailed financial data. Use synthetic outputs for language and layout testing whenever practical.

A report with small population cells could expose individuals in a new audience. Translating its labels does not remove the obligation to apply disclosure controls.

Confirm that sharing and retention are authorized. Mask or aggregate approved content before providing review materials, and avoid posting production logs to public issue trackers.

Ask reviewers to perform the real task

A translator who sees only isolated text may select the wrong meaning for ‘instance’, ‘batch’, ‘argument’, ‘severity’ or ‘header’. Give context: the command, a safe example, a screenshot and the outcome the operator needs to achieve.

Invite a fluent reader unfamiliar with the system to follow the localized help and run a read-only test. Observe misunderstandings without coaching them through every step.

Revise confusing instructions. The evaluation is whether a reader can complete the correct task safely, not whether every term has a literal counterpart.

Validate every supported platform

Windows, Linux, macOS and containers can differ in shell quoting, fonts, code pages, available binaries and filesystem paths. Even with the same sqlcmd variant, a command-line example may not behave identically under different hosts or login contexts.

Select the organization’s real deployment matrix rather than every theoretical system. Include the shell and terminal used to launch each test.

Mark untested environments as untested. Do not declare a single desktop success a universal platform guarantee.

Make ownership and limitations explicit

A translated sqlcmd manual should specify which version it describes, which databases and scripts were tested, who owns the terminology and which features are deliberately left untranslated. This gives future maintainers a stable handover instead of an unexplained set of localized strings.

Create a concise release record with source revision, translation revision, utility variant, key tests and known exceptions. Keep sensitive environment details in the appropriate private system.

Use the record when updating documentation after new SQL Server versions or client changes. Do not quietly replace an old verified example with an untested one.

Plan regression tests for future changes

Localization is not a one-off screenshot exercise. A future rewrite of an error message, a new output field or a switch to another sqlcmd variant can invalidate earlier approvals. A regression suite keeps the most important boundaries under surveillance.

Automate safe comparisons of row counts, identifiers, totals, process status and expected files. Reserve human review for language nuance and rendered readability.

Add a test whenever a real defect is discovered. The team should become more reliable with each language release rather than relying on collective memory.

Worked scenario: one query, two language editions

Imagine a fictional invoice-summary query that reports a count and a total. The team prepares an unchanged T-SQL batch and uses a separate approved message catalog for the report title. One invocation selects en and another selects fr. The numeric total, query predicate, source database and set of invoice IDs must remain the same. Only the user-facing heading and approved presentation conventions should differ. If a query itself changes to accommodate a translation, it receives a separate engineering review rather than being bundled into a language update.

Next, capture the output with a disposable -o path, verify the actual encoding and read it in the software used by the intended audience. Run a deliberately invalid language code and confirm that the script fails or discloses its fallback according to a documented contract. Finally, compare exit status and monitoring behavior on the true deployment host. This small exercise covers comprehension, security and reproducibility without requiring any real customer or financial records.

Prepublication checklist

Identify the installed sqlcmd variant and version.
Freeze the query, input fixture and expected numerical results.
Separate executable flags, SQL commands and human-facing translated text.
Validate all scripting-variable values at their eventual point of use.
Use approved secure connections and least-privilege read-only tests.
Check -i input, -o output, -u encoding and variant-specific -R or -f behavior.
Test batch termination, errors, stdout, stderr and expected exit status.
Open real exported artifacts in the receiver’s software and check Unicode and layout.
Obtain independent language, security and technical review.
Record supported platforms and explicitly identify untested combinations.

Frequently asked questions

Are sqlcmd (Go) and sqlcmd (ODBC) identical?

No. Microsoft documents distinct variants with differences in supported flags and behaviors. Identify the installed variant before writing or translating instructions.

Does -v translate my SQL query?

No. It supplies scripting variables for substitution. Localized guidance can explain the variables, but it should not change executable syntax or treat arbitrary substituted text as safe SQL input.

What does -u guarantee?

It selects Unicode output behavior for files according to the installed utility. It does not translate the content, ensure font coverage or validate that a reader can understand the result.

Why is -R not changing formatting in my Go installation?

Microsoft documents that sqlcmd (Go) ignores -R. Do not promise ODBC-style regional behavior for a different utility variant.

Should I translate GO or :Setvar in a code block?

No. Those are executable tokens. Translate the explanation around them, and test copied examples rather than modifying the command words.

Can I use -o without writing to the database?

A read-only SELECT can still create or overwrite an output file. Use an approved disposable destination and check the file-system side effects.

What if a translated report changes its counts?

Stop the release and compare database target, query text, scripting-variable values, selection conditions, input data and configuration. Localization should not silently change the result set.

How should I test a multilingual batch job?

Use synthetic data, valid and invalid inputs, the actual shell and sqlcmd variant, encoding checks, exit-status tests, rendered output review and a fixed numerical baseline.