+ Reply to Thread
Results 1 to 6 of 6

Thread: Localization

  1. #1
    Shield of Telara MaddBomber83's Avatar
    Join Date
    Jan 2011
    Location
    West Texas, USA
    Posts
    695

    Default Localization

    I'm maintaining Herald's Buff Warden Madd Patch. A german user just asked about plans to add localization.

    Now.... anyone with experience here have some recommendations on how to proceed?

    The addon is a buff addon. For most of the abilities it will simply find what buffs you can have on you and display them. This is called forth by the Inspect.Ability.List/Detail and so I'm assuming that portion does not need any localization.

    It also handles equivalent buffs. An example would be the different Inquisitor Armors, Mage Armors, Rogue Poisions and Warrior Bindings. It also handles items such as potions, food, powerstones and glow effects. All of these I have typed out the names in english and placed them in different tables for different activities. This section is what I believe the largest localization effort would take.

    Then there is the normal /slash commands and instructions.

    My initial thought (I'm assuming it is possible) is to ask the game if it is a German Client and if it is enable a separate section of code with the German text? And, hehe, testing will be neat being I'm not German ; ).

  2. #2
    Shield of Telara MaddBomber83's Avatar
    Join Date
    Jan 2011
    Location
    West Texas, USA
    Posts
    695

    Default

    I would replace all text with a variable, and this seperate section of code would populate these variables with the right text.

    Example:
    instead of :
    Code:
    HBWD_BA["Touch of the Shade"] = "Shadetouched"
    it would be:
    Code:
    HBWD_BA[Touch_of_the_Shade] = Shadetouched
    and the seperate section would be:
    Code:
    If English Then:
    Touch_of_the_Shade = "Touch of the Shade"
    Shadetouched = "Shadetouched"
    End
    If German Then:
    Touch_of_the_Shade = "Touch of the Shade"
    Shadetouched = "Schattenberührte"

  3. #3
    Plane Walker Imhothar's Avatar
    Join Date
    Feb 2012
    Posts
    439

    Default

    Try to reduce the need for localization as much as possible. For example, every buff has a "type" member, so for equivalent buffs instead of comparing names compare type IDs. Type IDs are the same in all languages.

    It's a common idiom to have a table with all the localized strings and have that populated on startup depending on language. For example:

    deDE.lua:
    Code:
    if(Inspect.System.Language() ~= "German") then
    	return
    end
    
    L = {
    	beer = "Bier",
    	hi = "Servus",
    }
    ruRU.lua:
    Code:
    if(Inspect.System.Language() ~= "Russian") then
    	return
    end
    
    L = {
    	beer = "пиво",
    	hi = "привет",
    }
    enEN.lua:
    Code:
    if(Inspect.System.Language() ~= "English") then
    	return
    end
    
    L = {
    	beer = "beer",
    	hi = "hello",
    }
    When you have one file per language you end up with only one of the strings loaded on startup. "return" on file level causes the rest of the file to be discarded, so in the end only one version of the language table is loaded. Make these files the first ones in your TOC file and you can simply use the strings like
    Code:
    frame:SetText(L.beer)
    If you use a simple name like I do with "L" then make sure the table is not a global variable!

    Remember to store your language files in UTF-8 encoding when using non-ASCII characters.
    Last edited by Imhothar; 04-25-2012 at 12:00 PM.

  4. #4
    Shield of Telara MaddBomber83's Avatar
    Join Date
    Jan 2011
    Location
    West Texas, USA
    Posts
    695

    Default

    Imhothar;

    Excellent suggestion. I like the way they would be separate files and only 1 of them would fully load. This should also make it easier for a German user to localize as I could just make a copy of the english translation and make it the German one, they could then go through and translate what needs to be translated and send me back the file.

    As for the type argument suggestion, I'll have to go through digging the code a bit to see if that is simpler than just including what that would fix into the translation files. The problem I run into here is I'm not the original author. Each time I go to tinker or fix something I first must dig through the code and reverse engineer his work, then apply the fix.

    Again, ty for the input.

  5. #5
    Plane Walker Imhothar's Avatar
    Join Date
    Feb 2012
    Posts
    439

    Default

    Just remember as a general rule of localization to never assume the positions of words being the same.
    Meaning, in German words might appear in other positions in a sentence than in English, so instead of using string concatenation like player .. " affected by " .. buff make it a format string string.format("%s affected by %s", player, buff).

    Lua does not have positional format arguments by default but you can use LibString for that, which adds string.formatn() where your translator might change the order of the format arguments to something like "%2s gewirkt auf %1s" and it will swap the arguments in string.formatn(fmt, player, buff) without you having to care about the language-correct usage of the format function.

    Just document in your translation file what the format arguments are and in what order they are passed.

  6. #6
    Champion Lorandii's Avatar
    Join Date
    Jun 2011
    Posts
    516

    Default

    Curseforge supports the localization app and keyword substitutions. Read this thread for details. http://forums.riftgame.com/beta-addo...nline-app.html

+ Reply to Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts