Localization practice questions

Worked examples for Localization

1. Question 1

   What is the output of the following program? ```java import java.text.NumberFormat; import java.text.ParseException; import java.util.Locale; public class Main { public static void main(String[] args) throws ParseException { NumberFormat fmt = NumberFormat.getNumberInstance(Locale.GERMANY); Number result = fmt.parse("1.234,56"); System.out.println(result); } } ```

   1. A. 1.234

      Arises from applying US-locale separator logic mentally: treating `.` as the decimal point, reading `1.234`, and stopping at the `,`. The formatter is a Germany-locale instance, where `.` is the grouping separator and is stripped rather than treated as a decimal point, so parsing does not stop there.

   2. B. 1234.56Correct answer

      The Germany locale designates `.` as the thousands grouping separator and `,` as the decimal separator. `parse("1.234,56")` therefore strips the grouping dot to obtain 1234 and interprets the comma as the decimal point, producing a `Double` with value 1234.56. `System.out.println` calls `Double.toString`, which renders the value as `1234.56` (`NumberFormat.parse` Javadoc, Java 21).

   3. C. 1.23456

      Reverses the German separator roles: if `.` were the decimal separator and `,` were the grouping separator (the US convention, not the German one), one might read `1.234,56` as `1` decimal-point `234` grouping `56` = `1.23456`. In the Germany locale those roles are the reverse of that, so this value is not what the formatter produces.

   4. D. Throws `java.text.ParseException`

      `"1.234,56"` is a well-formed German-locale number: `.` groups the thousands and `,` marks the decimal point. The Germany-locale formatter accepts it without error. `ParseException` is thrown only when the input string does not conform to the locale's expected number format.

   Explanation

   A `NumberFormat` returned by `getNumberInstance(Locale)` is locale-sensitive and uses that locale's own grouping and decimal separators during parsing as well as formatting. The Germany locale designates `.` as the thousands grouping separator and `,` as the decimal separator—the reverse of US conventions—so `parse("1.234,56")` strips the grouping dot to obtain 1234 and interprets the comma as the decimal point, giving the `Double` value 1234.56; `System.out.println` then calls `toString()`, producing `1234.56`. The string is well-formed for this locale so no `ParseException` is thrown; the other numeric options arise from applying US separator logic or reversing which character plays which role in the German convention.

2. Question 2

   A message template is localized with MessageFormat. What does this program print? ```java import java.text.*; import java.util.*; public class Main { public static void main(String[] args) { MessageFormat mf = new MessageFormat("It's {0} in {1}", Locale.US); System.out.println(mf.format(new Object[] {"noon", "Rome"})); } } ```

   1. A. Its noon in Rome

      Spots that the quote is swallowed but still expects substitution. An unterminated quote suppresses every placeholder after it, so {0} and {1} are never replaced.

   2. B. It's noon in Rome

      What you get only by doubling the quote as It''s, the correct way to write a literal apostrophe. It assumes MessageFormat treats ' as ordinary text.

   3. C. Its {0} in {1}Correct answer

      In a MessageFormat pattern ' is the quoting character; the unterminated quote in It's runs to the end, consuming itself and leaving {0} and {1} as unrecognized literal text, so no arguments are substituted.

   4. D. An IllegalArgumentException is thrown

      Assumes an unbalanced quote is a malformed pattern. MessageFormat is forgiving: an unterminated quote simply runs to the end of the pattern rather than throwing.

   Explanation

   Trace: in a MessageFormat pattern the single quote is not an apostrophe — it is the quoting character. The `'` in `It's` opens a quoted section, and because no closing quote ever appears, everything from that point to the end of the pattern is treated as literal text. The quote itself is consumed (it does not appear in the output) and the `{0}` and `{1}` inside the quoted run are never recognized as format elements, so the arguments "noon" and "Rome" are never substituted. The result is `Its {0} in {1}`. Why the others are wrong: `It's noon in Rome` is what you get only if you double the quote — `It''s {0} in {1}` — which is the correct way to write a literal apostrophe. It assumes MessageFormat treats `'` as ordinary text. `Its noon in Rome` spots that the quote is swallowed but still expects substitution to happen, missing that an unterminated quote suppresses every placeholder after it. `An IllegalArgumentException is thrown` assumes an unbalanced quote is a malformed pattern. MessageFormat is forgiving here: an unterminated quote simply runs to the end of the pattern. (Supplying too few arguments is likewise not fatal — an unmatched placeholder is left in place as `{1}`.) Exam tip: any apostrophe in a MessageFormat pattern must be written `''`. This is the single most common MessageFormat bug in real resource bundles, where a translator's "don't" silently kills the rest of the message. The reverse trap: this quoting rule belongs to MessageFormat (and DecimalFormat/SimpleDateFormat patterns), not to String.format — `String.format(Locale.US, "It's %s", "noon")` prints the apostrophe just fine.

3. Question 3

   A resource bundle is resolved successfully, but the requested key exists in none of the bundles in its parent chain. What does bundle.getString("missing.key") do?

   1. A. Returns null

      The API contract is fail-fast: it throws rather than returning null.

   2. B. Returns the key itself as the value

      Echoing the key back as its value is a convention of some third-party frameworks, not of java.util.ResourceBundle.

   3. C. Throws MissingResourceExceptionCorrect answer

      Correct: getString (via getObject) searches the bundle and walks up its parent chain, and when the key is absent everywhere it throws MissingResourceException — the same exception raised when no bundle can be found at all.

   4. D. Returns an empty string

      Returning an empty string would silently hide the missing translation; the JDK refuses to guess.

   Explanation

   ResourceBundle lookup is fail-fast rather than lenient: getString delegates to getObject, which searches the resolved bundle and every bundle in its parent chain, and signals a genuinely missing key by throwing MissingResourceException instead of returning null, an empty string, or the key itself. The same exception covers two different failures — no bundle found for the base name, and key not found anywhere in the chain. getString additionally throws ClassCastException if the stored value exists but is not a String.

4. Question 4

   What does this program print? ```java import java.time.*; import java.time.format.*; import java.util.*; public class Main { public static void main(String[] args) { LocalDate d = LocalDate.of(2024, 3, 5); DateTimeFormatter f = DateTimeFormatter.ofLocalizedDate(FormatStyle.MEDIUM).withLocale(Locale.US); System.out.println(f.format(d)); } } ```

   1. A. 05/03/2024

      A day-first numeric layout (en-GB SHORT). It assumes the formatter follows the platform or ISO order, but withLocale(Locale.US) pins the US month-first form, and MEDIUM is not all-numeric anyway.

   2. B. March 5, 2024

      The LONG style, with the month spelled out in full. Reading MEDIUM as the readable middle option lands here; MEDIUM uses an abbreviated month.

   3. C. Mar 5, 2024Correct answer

      ofLocalizedDate(MEDIUM) with Locale.US uses an abbreviated month, an unpadded day, and a four-digit year, giving Mar 5, 2024.

   4. D. 3/5/24

      The SHORT style, all-numeric with a two-digit year. It is what FormatStyle.SHORT gives, not MEDIUM.

   Explanation

   Trace: ofLocalizedDate builds a formatter whose pattern is looked up from the locale data for the requested FormatStyle. withLocale(Locale.US) pins that locale explicitly, so nothing depends on the machine's default. For en-US, the MEDIUM date style is an abbreviated month, the day, then a four-digit year: `Mar 5, 2024`. Note the day is not zero-padded. Why the others are wrong: `3/5/24` is the SHORT style — all-numeric with a two-digit year. It is what you get from FormatStyle.SHORT, not MEDIUM. `March 5, 2024` is the LONG style — the month spelled out in full. Students who read MEDIUM as "the middle one, so the readable one" land here. `05/03/2024` is a day-first numeric layout (en-GB SHORT). It encodes the belief that the formatter's locale follows the platform or the ISO order rather than the Locale you handed it; because the Locale is explicit, the US month-first form is used. Exam tip: the four styles for en-US dates ladder as SHORT `3/5/24`, MEDIUM `Mar 5, 2024`, LONG `March 5, 2024`, FULL `Tuesday, March 5, 2024`. Learn the ladder, not one entry. The reverse trap: ofLocalizedDate on a LocalDate is fine, but ofLocalizedDateTime or ofLocalizedTime applied to a LocalDate throws DateTimeException at format time — the temporal must carry the fields the style asks for.

5. Question 5

   Which is the recommended way to obtain a Locale for language "fr" and country "CA" in Java 21?

   1. A. new Locale("fr", "CA")

      This still compiles but has been deprecated since Java 19; the question asks for the recommended form.

   2. B. Locale.forLanguageTag("fr_CA")

      forLanguageTag expects BCP 47 hyphens ("fr-CA"); with an underscore the tag is ill-formed and its subtags are silently dropped, yielding a useless locale.

   3. C. Locale.getInstance("fr", "CA")

      Locale has no public getInstance factory.

   4. D. Locale.of("fr", "CA")Correct answer

      Correct: Java 19 deprecated the Locale constructors, so the static factory Locale.of("fr", "CA") is the recommended Java 21 idiom (and may return a cached instance), alongside constants like Locale.CANADA_FRENCH.

   Explanation

   Since Java 19 the Locale constructors are deprecated in favor of the static Locale.of factories, which are the current idiom for building a locale from language and country codes (predefined constants are also available). The language-tag factory is a different tool that expects hyphenated BCP 47 input and silently discards malformed subtags rather than throwing, so it is not interchangeable with underscore-style codes. No public getInstance factory exists on Locale at all.

6. Question 6

   What does this program print? ```java import java.text.*; import java.util.*; public class Main { public static void main(String[] args) { NumberFormat nf = NumberFormat.getIntegerInstance(Locale.US); System.out.println(nf.format(2.5) + " " + nf.format(3.5) + " " + nf.format(1234.5)); } } ```

   1. A. 3 4 1,235

      Assumes HALF_UP rounding — the rule taught in school and used by Math.round, but not the NumberFormat default. The default is HALF_EVEN, so 2.5 rounds down to 2 and 1234.5 down to 1234.

   2. B. 2 4 1,234Correct answer

      An integer instance rounds (not truncates) with HALF_EVEN by default, so a value exactly halfway goes to the nearest EVEN neighbour: 2.5→2, 3.5→4, 1234.5→1234; grouping is on for a US instance, so 1234 prints with a comma.

   3. C. 2 4 1234

      Gets the HALF_EVEN rounding right but assumes getIntegerInstance turns grouping off. It does not — isGroupingUsed() stays true, so the thousands separator appears in 1,234.

   4. D. 2 3 1,234

      Assumes an integer instance truncates the fraction like an (int) cast; it rounds, and with HALF_EVEN 3.5 rounds up to 4, not down to 3.

   Explanation

   Trace: an integer instance drops the fraction, but it *rounds* rather than truncates, and the rounding mode of a NumberFormat is HALF_EVEN ("banker's rounding") by default — a value exactly halfway goes to the nearest **even** neighbour. So 2.5 rounds down to 2 (2 is even), 3.5 rounds up to 4 (4 is even), and 1234.5 rounds down to 1234 (1234 is even). Grouping is on by default for a US instance, so 1234 prints with a comma. Why the others are wrong: `3 4 1,235` assumes HALF_UP — the rule taught in school, and the rule Math.round uses, but not the NumberFormat default. `2 3 1,234` assumes an integer instance truncates the fraction like an (int) cast; it rounds. `2 4 1234` gets the rounding right but assumes getIntegerInstance turns grouping off. It does not — isGroupingUsed() stays true, so the thousands separator appears. Exam tip: NumberFormat.getRoundingMode() is RoundingMode.HALF_EVEN out of the box, and this bites only on exact ties — every question that shows you a .5 is testing it. The reverse trap: getIntegerInstance also sets parseIntegerOnly, so parsing "12.75" with it yields 12, not 12.75.

7. Question 7

   A US-locale NumberFormat is obtained with `NumberFormat nf = NumberFormat.getInstance(Locale.US);` and used only to parse strings, never to format them. Which two statements about `nf.parse(String)` are correct? (Choose two.)

   1. A. `nf.parse("x1,234.5")` returns null, so the caller must null-check the result.

      Assumes parse signals failure with a sentinel value. Nothing is parseable at index 0, so it throws the checked ParseException (error offset 0); the String-only overload never returns null.

   2. B. `nf.parse` returns a BigDecimal by default, so no precision is lost on values such as "1,234.5".

      Confuses the default with the opt-in. isParseBigDecimal() is false unless you cast the NumberFormat to DecimalFormat and call setParseBigDecimal(true); by default "1,234.5" comes back as a Double.

   3. C. `nf.parse("1,234")` returns a Long, not a Double — the returned Number's runtime type depends on the value parsed.Correct answer

      The underlying DecimalFormat returns the narrowest of Long or Double that can hold the value, so an integral value that fits in a long arrives as a Long; code that blindly casts the result to Double throws ClassCastException.

   4. D. `nf.parse("1,234.5x")` returns 1234.5 — parsing stops at the first character that cannot be used and the rest of the text is ignored.Correct answer

      parse reads a PREFIX left to right and stops at the 'x'; a value has already been parsed by then, so no exception is raised and the trailing garbage is silently dropped, returning a Double of 1234.5.

   Explanation

   NumberFormat.parse(String) parses a *prefix*, not the whole string. It fails only when it cannot parse anything from the start of the text. Why `nf.parse("1,234.5x") returns 1234.5 ...` is correct: parsing runs left to right and stops at the `x`, which cannot continue a number. A value has already been parsed by then, so no exception is raised and the trailing garbage is silently dropped; the call returns a Double of 1234.5. Why `nf.parse("1,234") returns a Long ...` is correct: the underlying DecimalFormat hands back the narrowest of Long or Double that can hold the parsed value, so an integral value that fits in a long arrives as a Long. Code that blindly casts the result to Double throws ClassCastException. Why the others are wrong: `nf.parse("x1,234.5") returns null ...` encodes the belief that parse signals failure with a sentinel value. It does not: nothing is parseable at index 0, so it throws the checked java.text.ParseException with error offset 0. The String-only overload never returns null — its sibling parse(String, ParsePosition) is the one that returns null and reports an error index. `nf.parse returns a BigDecimal by default ...` confuses the default with the opt-in. DecimalFormat.isParseBigDecimal() is false unless you cast the NumberFormat to DecimalFormat and call setParseBigDecimal(true); only then does "1,234.5" come back as a BigDecimal. Exam tip: two things get tested about parse — it returns Number, so the runtime type (Long vs Double) matters, and it throws the *checked* ParseException, so an unhandled call is a compile error rather than a runtime surprise. The reverse trap is assuming trailing junk is an error: it is not, but leading junk is.

8. Question 8

   What is the output of the following program? ```java import java.text.NumberFormat; import java.util.Locale; public class Main { public static void main(String[] args) { NumberFormat nf = NumberFormat.getNumberInstance(Locale.US); System.out.println(nf.format(1234.56789)); } } ```

   1. A. 1,234.568Correct answer

      The US number-format pattern #,##0.### allows zero to three fraction digits and inserts a comma grouping separator every three whole-number digits. 1234.56789 is rounded at the fourth decimal place to 1234.568, then the comma is inserted to yield 1,234.568.

   2. B. 1,234.56789

      All five decimal digits are preserved, as if the formatter performed no rounding. In reality, getNumberInstance returns a DecimalFormat whose pattern is #,##0.### — the three trailing # symbols each represent one optional fraction digit, capping the maximum at three, so excess digits are rounded away before output.

   3. C. 1,234.57

      Two fraction digits is the default for getCurrencyInstance (pattern #,##0.00), not getNumberInstance. The number-format pattern for Locale.US is #,##0.### which permits up to three fraction digits, not two, so the value rounds to three places rather than two.

   4. D. 1234.568

      The rounding to three fraction digits is correct, but the grouping separator is absent. The US number-format pattern includes a comma grouping separator every three whole-number digits; omitting it produces a different string than what the formatter actually emits.

   Explanation

   NumberFormat.getNumberInstance(Locale.US) wraps a DecimalFormat using the pattern #,##0.###: a maximum of three fraction digits (the trailing ### symbols are each optional) and a comma grouping separator every three whole-number digits. A value with more decimal places is rounded to three, not truncated or fully preserved. The currency factory method, which enforces exactly two fraction digits via the pattern #,##0.00, is a separate call and has no bearing here.