Rendering localized text, method 'getLeading' is not callable

SDK 1.9.3, Windows 11

I'm working on infrastructure, this time on menus and such (work based on the gridview list example). So far, so good. So then I want to fold in some i18n (internationalization), looking to add a menu item to switch from English to Japanese... logical first step there is to move my hardcoded English strings to looking up something from 'en.strings' and switch calling the 'drawLocalizedxxxx' functions.

Every time I try to use the 'drawLocalized' functions I get a font related error: "CoreLibs/graphics.lua:282: method 'getLeading' is not callable (a nil value)"

I know the key lookup is successful, because I swapped in something that wouldn't be successful and got complaints about it rather than the graphics.lua error :wink: .

I think the 'drawLocalized' syntax is correct as I'm just adding the language string ("en") to the method signature, and the docs say that moving from this:, x, y, width, height, [leadingAdjustment, [truncationString, [alignment, [font]]]])

(where the optional font isn't specified)

to this:, x, y, width, height, [leadingAdjustment, [truncationString, [alignment, [language]]]])

(and the 'en.strings' lookup is happening/successful as there is no complaint)

I've reproduced the issue using a modification of the 'Game Template' example (attached). Working:

Switched to calling the localization equivalent, not working:

(the 'SetupDiGetDeviceRegistryProperty' stuff I'm pretty sure is unrelated and is instead due to setting the Simulator executable properties to high definition scaling to sync with my main monitor)

The way I build/run the reproduction (Windows batch file):

@echo off
pdc "Game Template/Source" gt.pdx
playdatesimulator gt.pdx

Game (6.1 KB)

1 Like

This is because the language you placing at the end of this is being treated as a font by the underlying drawTextInRect used.

Here is a workaround for now, all I am doing here is grabbing the localized text then popping the language off the end of the args so that it doesn't get treated as a font:

import "CoreLibs/graphics"

local gfx <const> = = function(text, x, ...)
  local language
  if (type(x) == "userdata") then
    language = select(4, ...)
    language = select(7, ...)
  local localizedText = gfx.getLocalizedText(text, language)
  local fix = table.pack(...)
  table.remove(fix, 7)
  gfx.drawTextInRect(localizedText, x, table.unpack(fix))

function playdate.update()
  gfx.drawLocalizedTextInRect("test", 0, 0, 100, 20, nil, "...",, "en")

or if you don't want to swizzle, this is essentially the same as drawLocalizedTextInRect:

gfx.drawTextInRect(gfx.getLocalizedText("test", "en"), 0, 0, 100, 20, nil, "...",

Definitely a bug!

Edit: you don't have to specify the localization either fwiw.


Ouch! >.<

I'll go that route for now, thanks!

Another option is just dropping the en. The lookup for the text will automatically choose the correct language. So unless you want to "force" the text to English (and why not just use a reg drawTextInRect then?) then you would be fine dropping it.

I was hoping to twist the arm of the localization code to support other languages (hadn't gotten to that point yet because of the bug)... and have my own 'Languages' menu item, ex: 'es.strings', etc. :

1 Like

Nice! It does not seem like it would be too hard to add more languages, I would guess one the bottle necks is in creating fonts to support their diffs.

Well, it was a nice thought... but no workee. The call to 'getLocalizedText' only works with "en" or "jp" (and nothing else). I've got more questions there, but this is becoming off-topic for this bug report, will file question(s) elsewhere.

Cool! And yeah - it probably won’t work, locales are hardcoded at the OS layer. These apis interact with that. You very well could code you your own lookup that falls back on official for supported languages though. It wouldn’t be too bad.

I would say more language support falls under a feature request.

edit: I just realized what you mean by twist the arm heh, I thought you meant light a fire under panic to support more

I've spent last evening and this morning digging into the font support in some depth, and things seem pretty hardcoded to solely: 7-bit ASCII, Hiragana and Katakana... where 'things' include the font format itself. Given the restrictions of the platform that seems fairly reasonable. I would like to see support for ISO Latin-1, though... as well as extend the text localization mechanism to not be so strict about which files to allow or not ('es' in addition to 'en', etc.). But at this point I'm happy enough to be able to switch between English and Japanese :wink: .

Ah, no, I wouldn't do that :slight_smile: .

1 Like

I finally got a chance to take a look at this, I didn't realize it was as broken as it currently is! I'll try to get a fix in for the next SKD release.