Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Siri shortcut translation files are not handled #151

Open
patricks opened this issue Oct 7, 2019 · 10 comments · May be fixed by #241
Open

Siri shortcut translation files are not handled #151

patricks opened this issue Oct 7, 2019 · 10 comments · May be fixed by #241
Labels
enhancement Ongoing PR exists, but not merged yet. Priority: Medium

Comments

@patricks
Copy link
Contributor

patricks commented Oct 7, 2019

I have an app which supports Siri Shortcuts, therefore I have a .intentdefinition file. This file is also translated, but it looks like, BartyCrouch ignores this file.

@Jeehut
Copy link
Member

Jeehut commented Oct 16, 2019

I haven't used Siri Shortcuts yet, so I'm not aware of this file. Can you please further explain how this is localized? Are there any Strings files? Can you list the different file paths? Are they below something like en.lproj?

It is totally possible that we didn't cover those files yet. While I'm not sure how BartyCrouch could improve translation there, I'm definitely open for a PR that adds support for Siri Shortcuts.

@patricks
Copy link
Contributor Author

The files are located in the Base.lproj, en.proj locations. The .intent file is a xml file.

@patrickferreira
Copy link

+1
It would be amazing if bartycrouch could handle the translations of custom intents.
Let me know if you need any further info.

@Jeehut
Copy link
Member

Jeehut commented Dec 31, 2019

@patrickferreira I understand that. But my question, how BartyCrouch could help here is still not answered. I'm assuming you expect something similar to what BartyCrouch does with Interface Builder files, right? (Automatically updating the .strings files with new translatable texts in the IB files.) That's only supported by BartyCrouch because Apple has a tool (namely extractLocStrings) which does that for us. If there's a similar tool for the .intent files, it might be easy to add support for intents as well. If not, things get a little more complicated.

@letatas
Copy link

letatas commented Jan 7, 2020

For your information .intentdefinition files are xml property lists, so may be the same workflow that is used for classic .plist files can be applied with them?

@Jeehut Jeehut modified the milestone: Version 4.0 Apr 16, 2020
@NMAC427
Copy link
Contributor

NMAC427 commented Oct 19, 2020

I'm experiencing the same issue. And it still hasn't been fixed in version 4.x. Would be great if someone could take a look at this.

@Jeehut
Copy link
Member

Jeehut commented Oct 19, 2020

@NMAC427 Thank you for bringing this up again. As I have noted above, BartyCrouch is currently based on tools from Apple (namely extractLocStrings) which don't support XML/PLIST files (AFAIK), so it's not trivial to add support for Siri shortcut translation files. But I'm actually thinking about switching to a completely custom implementation for the next major version of BartyCrouch where I could also take other file types like the .intentdefinition file into consideration. I can't promise any time when I will be working on it though as I'm developing BartyCrouch in my free time. If someone was to add support for these files, I'd love to review & merge a PR for it though.

@NMAC427
Copy link
Contributor

NMAC427 commented Oct 19, 2020

But I'm actually thinking about switching to a completely custom implementation

A few years ago I developed such a system myself for my own projects. It definitely is possible but the main problem with it is that Apple constantly creates breaking changes (i.e. new platform or new ui element). As long as Apple provides tools to generate .string files from storyboards, I would use their tools. That way you automatically get support for new ui elements and platforms. (This is also akin to the Unix philosophy where you build programs on top of other programs instead of reimplementing everything yourself.)

Instead I would only create a custom implementation for handling files (like .intentdefinition) where Apple doesn't provide any tools for creating the derived .string files.

@Jeehut
Copy link
Member

Jeehut commented Oct 19, 2020

@NMAC427 Good points and don't worry, I won't be reimplementing anything that changes often and Apple (or the community) already provides an updated tool for. But extractLocString for example handles NSLocalizedString and there not much has changed over time. By implementing a custom approach, I can add support for more customization options, I can add some kind of plugin system where .intentdefinition support could be added easily etc.

But I will think about the design choices when I have the time to actually start working on this.

@RSickenberg
Copy link

Hello, is this still ongoing?

@FlineDevPublic FlineDevPublic added Ongoing PR exists, but not merged yet. Priority: Medium labels Jan 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Ongoing PR exists, but not merged yet. Priority: Medium
7 participants