Okay, here's a summary of the provided transcript in the requested bullet-list format:

Not Getting Lost in Translation - Daniela Engert - Meeting C++ 2024

• 0:28 Introduction to Translation: The talk explores translation in a broad sense, encompassing both human languages and computer languages (compilation).
• 1:48 Example Machine: Engert introduces a machine built by her company that inspects train wheel axles for defects non-destructively.
• 5:01 Initial String Handling (2009): The company initially used boost::format for string concatenation, supporting only German.
• 5:48 The Need for Multilingual Support (2014): Due to growing international business, the need to support multiple languages (starting with Czech) arose.
• 5:55 Choosing a Translation System: The company evaluated translation systems, focusing on maturity, ecosystem (editors, build system integration), and ease of use for non-technical translators.
• 5:71 Gettext: gettext use text files, which are prone to fewer errors for those not familiar with JSON or XML.
• 5:83 Gettext and Boost.Locale: They opted for gettext, a widely used C library, and Boost.Locale, which implements similar algorithms.
• 5:91 Message Catalogs: The core concept is "message catalogs," collections of translations for specific languages/domains.
• 5:99 Standardization of Gettext: The gettext system was standardized at the beginning of the current year (likely referring to 2024, despite the video's listed date of 2025).
• 1:00:14 Translation Workflow: The process involves marking translatable strings, extracting them using tools (xgettext), creating language-agnostic .po files, translating those, and compiling them into machine-readable .mo files.
• 1:01:54 Portable Output (PO) Files: One .po file is created for each region, country, or customer.
• 1:02:34 PO File Structure: .po files are text files, specifying the language (e.g., Czech) and the number of plural forms.
• 1:03:16 Plural Forms: Different languages have different numbers of plural forms (e.g., Czech has singular, dual, and plural).
• 1:03:51 Checking Formatting Specifications: A crucial step involves verifying that formatting specifications (like those from printf or std::format) are correctly translated.
• 1:04:33 Compiled output (MO) Files: The compiled .mo (machine object) files are binary and optimized for machine interpretation, not human readability.
• 1:05:05 Unicode and Plural Rules: The Unicode Standard (specifically the Common Locale Data Repository, CLDR) provides machine-readable rules for plural forms in various languages.
• 1:07:50 Plural Rules as C Expressions: These plural rules are expressed as single-line C expressions.
• 1:08:08 Boost.Locale Issues: Engert criticizes Boost.Locale for performing unnecessary encoding conversions (to Unicode) on every translation, leading to string allocations and heap clutter.
• 1:09:21 Transition to fmt::format (2018): The company switched to fmt::format (later std::format) for improved performance and features, coinciding with a move to C++14.
• 1:10:07 Change in Formatting Approach: The transition involved moving from separate formatting specifiers and arguments to a combined approach, using type lists.
• 1:11:11 Type Lists and Code Bloat: Type lists can lead to template instantiation explosion, but fmt::format mitigates this with a type-erased interface.
• 1:12:23 Type-Based Metaprogramming: The talk delves into type-based metaprogramming techniques used in fmt::format, including template specialization, overload resolution, and noexcept-based metaprogramming.
• 1:13:43 Spinae and Metaprogramming Costs: The goal is SFINAE (Substitution Failure Is Not An Error), but type-based metaprogramming can be computationally expensive for the compiler (the "Rule of Haase").
• 1:15:02 Function Definition: Explains general idea of a function.
• 1:16:06 Compile-Time vs. Runtime Parameters: Distinguishes between function parameters in parentheses (runtime) and template parameters in angle brackets (compile-time).
• 1:17:32 Adoption of std::format (C++20, 2021): The company adopted std::format (P2216) in C++20, which changed the signature of the formatting functions.
• 1:18:38 std::format Signature Change: The formatting string is now a distinct type with a consteval constructor, taking both the string view and the type list of arguments.
• 1:19:56 consteval: consteval functions can only be evaluated at compile time, unlike constexpr functions.
• 1:20:40 Constant Evaluation: Constant evaluation involves the compiler evaluating constant expressions during compilation.
• 1:23:47 consteval Constructor Implications: The consteval constructor allows for compile-time checks of format string validity and argument type matching, preventing runtime exceptions.
• 1:25:35 Further Translation Needs: The company continued to add more language support.
• 1:26:01 Limitations with std::format and Translations: The consteval nature of std::format's constructor prevents runtime string translation selection (e.g., choosing between English, French, etc., at runtime). The output is a fixed string_view.
• 1:28:04 Custom Overload: Engert's solution was to create a custom overload of the formatting function, mimicking std::format but allowing for runtime language selection.
• 1:29:03 Custom Type and Constructor: A new type (similar to std::basic_format_string) is introduced, with a consteval constructor that performs compile-time checks, deferring to std::format for validation.
• 1:30:21 Compile-Time Hash Calculation: To avoid storing all possible translated strings, the hash of the untranslated string is calculated at compile time.
• 1:31:44 Storing Only a Number: The only data member stored in the front-end is a number (the hash), enabling efficient lookup of the correct translation at runtime.
• 1:32:52 Remaining Questions: Three questions remain: 1) Which argument determines the plural form? 2) How to get the value of that argument? 3) How to handle translation of arguments themselves?
• 1:33:29 Handling Argument Translation: Type-based metaprogramming is used to map argument types to functions that either perform translation or not.
• 1:34:14 Future C++ Features: C++26 features (package index, P2996 reflection) would simplify the remaining questions, but a C++20 solution was needed.
• 1:35:10 Heterogeneous Sequences and Folds: The solution involves working with type lists (heterogeneous sequences) using folds (a concept from functional programming).
• 1:37:18 Implementing find_if on a Type List: A custom find_if implementation for type lists is demonstrated, using folds and predicates, to determine the index of the argument controlling the plural form.
• 1:40:47 Retrieving Argument Values: The addresses of argument objects are taken, type-erased to numbers, stored in a homogeneous array, and then indexed to retrieve the correct value, with the type recovered using the predicate.
• 1:42:11 Type-Based Metaprogramming for Translation: Structs with template parameters as function parameters are used for pattern matching to apply different translation logic based on argument types.
• 1:43:15 Compile-Time Translation Backend: Engert describes an attempt to implement the entire translation backend (table management) at compile time.
• 1:43:48 Integration Test at Compile Time: An integration test is presented that verifies the translation process at compile time, involving the build system, string extraction, .po file compilation, and embedding the resulting .mo file data into the source code.
• 1:47:14 Compile-time testing and verification is valuable.
• 1:47:53 Runtime Testing: The same test can also be performed at runtime, loading the .mo file from the filesystem.
• 1:48:32 Resources related to translations.
• 1:49:11 Potential Standard Library Contribution: Engert suggests the possibility of contributing this translation library to the C++ standard committee.
• 1:50:01 Q&A:
  • Q (Martin R.): What artifact is sent to the translating company? A: The extracted strings (output of the scanning process) in .po format.
  • Q (Martin R.): How to handle non-text translation (e.g., floating-point number formatting)? A: The system doesn't handle that; it focuses on string translation, specifically plural forms.
  • Q: Why not use C++20's std::embed? A: The compiler didn't support it at the time.
  • Q: Why use fold expressions instead of recursive template expansion? A: Fold expressions are easier to read and potentially more performant, avoiding expensive type-based metaprogramming (Rule of Haase).
  • Q (Linguistic): How are different plural forms based on grammatical case handled (e.g., German articles)? A: The system works with complete sentences, not individual words, avoiding issues with grammatical case variations. It translates the entire context.
  • Q: Is it possible to include multiple different language options in a formatted string? A: Yes, the library is versatile and supports supplying different cardinals (plurality values) for different parts of the string, allowing mixing languages.