Add support for localized assets (images and other data)

[EliteMasterEric]

Developers may wish to localize more than just the text within their application. Consider the use case where the user is prompted to choose their language before the game starts. This is fine, but as soon as the game starts, the logo appears, and it's unlocalized!

In order to solve this problem, developers must either:

• Write the name of their game in an in-engine font, which would take a lot of work, likely won't look right, and may bring flack from the graphic designers and trademark legal experts.
• Manually determine the user's selected game language, determine the appropriate font file to load, and retrieve it. Retrieving things manually based on the user's selected language is what Firetongue was built to abstract AWAY from developers!

There is a third solution. Around this line of the Firetongue implementation, the getText functions for each appropriate framework are called.

https://github.com/larsiusprime/firetongue/blob/ca5acb60c097ba3d77b7d26881f6048e7d54ff51/firetongue/Getter.hx#L92

The solution would be to simply add some new functions for getBytes and getImage alongside the getText implementation, and allow the user to call them to retrieve those assets, like so:

var sprite:FlxSprite = new FlxSprite().loadGraphic(tongue.getImage('menu/logo'));

[larsiusprime]

Cool idea!

On Thu, Sep 23, 2021 at 4:11 PM Eric Myllyoja @.***> wrote:

Developers may wish to localize more than just the text within their application. Consider the use case where the user is prompted to choose their language before the game starts. This is fine, but as soon as the game starts, the logo appears, and it's unlocalized!

In order to solve this problem, developers must either:

• Write the name of their game in an in-engine font, which would take a lot of work, likely won't look right, and may bring flack from the graphic designers and trademark legal experts.
• Manually determine the user's selected game language, determine the appropriate font file to load, and retrieve it. Retrieving things manually based on the user's selected language is what Firetongue was built to abstract AWAY from developers!

There is a third solution. Around this line of the Firetongue implementation, the getText functions for each appropriate framework are called.

https://github.com/larsiusprime/firetongue/blob/ca5acb60c097ba3d77b7d26881f6048e7d54ff51/firetongue/Getter.hx#L92

The solution would be to simply add some new functions for getBytes and getImage alongside the getText implementation, and allow the user to call them to retrieve those assets, like so:

var sprite:FlxSprite = new FlxSprite().loadGraphic(tongue.getImage('menu/logo'));

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/larsiusprime/firetongue/issues/41, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFUN6BIQLSDDGT3RTAQKNDUDOJZRANCNFSM5EUSAK2Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

-- www.fortressofdoors.com -- My design & business of game development blog

[EliteMasterEric]

@larsiusprime Localization support is one of the features I want to provide in my current project, and to implement it in the manner that I want, I'd need to implement this feature.

I'm wondering your opinion here, do you think it makes more sense to:

1. Add the capability to retrieve localized assets using Firetongue. This will require applications that want to use it to specifically request that a given asset be localized.
   • The main obstacle to this is that it requires users to change every part of their code that retrieves graphics assets, making it more difficult to migrate.
   • Since this would still access the appropriate library's asset management system, Polymod would inject itself into that logic and would be supported without additional work.
2. Add optional Firetongue integration to Polymod, in a similar fashion to OpenFL. This would allow you to provide a Firetongue instance during mod initialization, in which case Polymod would add checking for locale-specific assets to its library injection logic.
   • Using similar asset replacement logic allows for seamless integration of localized assets, especially in mods (translate any asset to any language using mods, hooray!).
   • However, this creates the issue where Firetongue itself is left with no native asset translation utility, requiring that users install an extra library to provide it.

Also, random aside, what do you recommend developers use for language icons if NOT country flags? This was mentioned in your documentation but not really elaborated on.

[larsiusprime]

Hmmm, so you can already use firetongue in a hacky way to do localized assets.

1) Just have a string for some of your localization-sensitive assets. Fetch the localized string and manually pass that to your asset fetch. I actually do this in a few places in my own game.

2) Adding an entire asset overriding backend to firetongue feels like overkill and duplication. If we want to go in that direction I think it's better to have people rely on polymod which is actually designed for that sort of thing, and it might make sense to add hooks to polymod to let it detect that you're currently running the game in Swedish so it grabs the Swedish title screen or whatever.

This gives devs two very easy and flexible options: just wanna use firetongue alone? Then you have to be aware of where you want a localizable asset and construct its asset name by calling a firetongue string so you can get "title_swedish.png" back or whatever. Want everything to happen automagically? Install polymod too, set up the necessary loc folders in your asset file, and then pass polymod instance to firetongue on startup with the necessary configuration.

As for flags -- there really is no good option. Plenty of people use flags, but people can rightly get sensitive about it, there's really no great visual icon option I've thought of yet. I just list languages twice, once in their own language, once in the current one.

On Thu, Nov 25, 2021 at 2:41 AM Eric Myllyoja @.***> wrote:

@larsiusprime https://github.com/larsiusprime Localization support is one of the features I want to provide in my current project, and to implement it in the manner that I want, I'd need to implement this feature.

I'm wondering your opinion here, do you think it makes more sense to:

1. Add the capability to retrieve localized assets using Firetongue. This will require applications that want to use it to specifically request that a given asset be localized.
   • The main obstacle to this is that it requires users to change every part of their code that retrieves graphics assets, making it more difficult to migrate.
   • Since this would still access the appropriate library's asset management system, Polymod would inject itself into that logic and would be supported without additional work.
2. Add optional Firetongue integration to Polymod https://github.com/larsiusprime/polymod, in a similar fashion to OpenFL. This would allow you to provide a Firetongue instance during mod initialization, in which case Polymod would add checking for locale-specific assets to its library injection logic.
   • Using similar asset replacement logic allows for seamless integration of localized assets, especially in mods (translate any asset to any language using mods, hooray!).
   • However, this creates the issue where Firetongue itself is left with no native asset translation utility, requiring that users install an extra library to provide it.

Also, random aside, what do you recommend developers use for language icons if NOT country flags? This was mentioned in your documentation but not really elaborated on.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/larsiusprime/firetongue/issues/41#issuecomment-978956936, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFUN6BSXDUCYEVBB32GSNTUNXZFDANCNFSM5EUSAK2Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

-- www.fortressofdoors.com -- My design & business of game development blog

[EliteMasterEric]

Superceded by larsiusprime/polymod#81.