42 Matching Annotations
  1. Sep 2020
  2. Aug 2020
    1. History is littered with brand names, logos, and taglines that were translated but not localized. Consequently, these brands completely missed their mark in the new target cultures. These examples show how words that are simply translated into another language without "in-country vetting" of the phrase’s true meaning and/or connotation, can be a multi-million dollar mistake.
    1. Find Games in Your LanguageIf you're using Search in a language other than English, then your language will be shown first in the language filter control, and that control will be moved to near the top of the search page.
  3. Jul 2020
  4. May 2020
  5. Apr 2020
  6. Mar 2020
    1. Then there’s markup inside each paragraph, like links and such. You could do it right in the translation strings, but your translator then needs to know how to handle the markup, and you risk duplicating knowledge if you go as far as to hard-code link URLs. What I do is split up the translations, but keep them under the same key: en.yml1 2 3 4 log_in_or_sign_up: text: "%{log_in} or %{sign_up} to do stuff." log_in: "Log in" sign_up: "Sign up" header.erb1 2 3 4 5 <%= t( :'log_in_or_sign_up.text', log_in: link_to(t(:'log_in_or_sign_up.log_in'), login_path), sign_up: link_to(t(:'log_in_or_sign_up.sign_up'), signup_path) ) %> This way, the translator sees no code or markup (except for the i18n interpolation syntax) and there is no duplication.
    2. You probably don’t want one translation key per sentence, though. It’s helpful for the translator to have context rather than a lot of short strings, and less fiddly on your part.
    3. If you ever need to work with external translators, it’s a bit of a pain sending both your YML files and a bunch of views like index.en.html.erb. For one thing, you need some code to find all those files and send them, and put them back after receiving the translations. For another, your translator must respect the markup and code of the template, and know not to translate them. And if you want to use tools like WebTranslateIt, it’s easier to stick to YML.

      Good point. Better to store translations in your I18n backend in the same place as your subject translations, etc. (which by default is in YAML file).

    1. Action View has the ability to render different templates depending on the current locale.For example, suppose you have an ArticlesController with a show action. By default, calling this action will render app/views/articles/show.html.erb. But if you set I18n.locale = :de, then app/views/articles/show.de.html.erb will be rendered instead. If the localized template isn't present, the undecorated version will be used. This means you're not required to provide localized views for all cases, but they will be preferred and used if available.

      This is one option, but there is another camp that says it's better to store translations in your I18n backend in the same place as your subject translations, etc.: https://thepugautomatic.com/2012/07/rails-i18n-tips/

    1. ActionController and ActionMailer default include AbstractController::Rendering directly or indirectly (ActionController::Metal::Rendering). AbstractController::Rendering uses ActionView as default library for its template rendering engine and includes AbstractController::ViewPaths and an instance of I18n proxy to find localized views. To learn more i'd like to refer to the ActionPack source code on github. To get to the point. ActionView allows you to use localisation in your templates: See Rails guide: Action View Overview , Chapter Localized views.

      Not a very detailed or good code dissection, but is kind of one.

    1. However imagine we are creating a format string in a separate file, commonly because we would like to internationalize it and we rewrite it as: <?php$format = 'The %s contains %d monkeys';echo sprintf($format, $num, $location);?> We now have a problem. The order of the placeholders in the format string does not match the order of the arguments in the code. We would like to leave the code as is and simply indicate in the format string which arguments the placeholders refer to. We would write the format string like this instead: <?php$format = 'The %2$s contains %1$d monkeys';echo sprintf($format, $num, $location);?> An added benefit is that placeholders can be repeated without adding more arguments in the code.
    1. Sometimes a single term is used in several contexts. Although it is one and the same word in English, it may need to be translated differently in some languages. For example, the word "Post" can be used both as a verb ("Click here to post your comment") and as a noun ("Edit this post"). In such cases, the _x() function should be used. It is similar to __(), but it has an additional second argument -- the context:
    1. Poedit and other tools can scan your .php files for references of __(), _e(), _n() and so on, and grab those strings for translation, which is awesome, because otherwise you’d have to manually add every single string. Now, when these tools come across _n() in our sources, they know it’s a plural thing, because of a special keyword setting which looks something like _n:1,2, meaning _n() takes at least two arguments, where the first argument is the singular, and the second argument is a the plural, so it grabs both strings. Let’s take a look at how Poedit and other tools will parse our function above: Hello there _n() on line 3! I’m supposed to grab two of your arguments because I have this smart keyword setting, but none of these arguments are strings, so I’ll just skip to the next match
    1. Quite a few times, there will be collisions with similar translatable text found in more than two places, but with different translated context. By including the context in the pot file, translators can translate the two strings differently.
    1. WordPress uses gettext libraries to be able to add the translations in PHP. In WordPress you should use the WordPress localization functions instead of the native PHP gettext-compliant translation functions.
    1. This is where the incredibly useful gettext filter comes in. If you take a peek at your plugin's code you'll see strings like this: .gist table { margin-bottom: 0; } <?php _e( 'Related Products', 'woocommerce' ); ?> view raw sample-translatable-string.php hosted with by GitHub You can easily translate these strings by adding a filter to your functions.php file: .gist table { margin-bottom: 0; } <?php /** * Change text strings * * @link http://codex.wordpress.org/Plugin_API/Filter_Reference/gettext */ function my_text_strings( $translated_text, $text, $domain ) { switch ( $translated_text ) { case 'Related Products' : $translated_text = __( 'Check out these related products', 'woocommerce' ); break; } return $translated_text; } add_filter( 'gettext', 'my_text_strings', 20, 3 );
    1. Poedit’s built in support for Crowdin, a great localisation management platform, makes collaboration a breeze. Access to all your projects and translate directly from the app.
    1. For this simple example, you can simply edit the .po file in your editor and add the translation to all the msgstr sets. For a larger, more complex set of translation, the GlotPress and Poedit tools exist to help.
    1. https://github.com/r18n/r18n claims:

      Crowdin — supports all of R18n, including pluralization, filters, etc.

      I couldn't find any mention of Rails on this site though.

  7. Aug 2019
  8. Jan 2019
    1. rodmann's most important tool in mapping the cortex was cytoarchitectonics
    2. One of the more influential localization schemes of this period was phrenology, developed by Gall and Spurzheim in the early 1800s (this movement is well known, so will only be summarized here)