You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I wanted to take a moment to express my appreciation for accent. It really is an awesome tool which regularly makes my day a lot easier (especially the extended activity log and the comments).
Idea
In order to migrate the last remaining projects to accent, we built a "middle layer" to enable the delivery of "over the air" updates to applications where the release process takes quite long or sometimes is even impossible (iOS apps for example). The most complex part is already solved by accent with the "versions" functionality. In order to now know which app version should get which versions of the translation, I just established a rather cumbersome naming scheme. Here is an example:
I'm just using semver ranges and prefix it with the platform (I share translations between both native codebases). This works quite well but also has some limitations and is quite error prone.
To support this "over the air" use case and make it more robust, an extension of the "Version" model would be needed. The following would by my idea:
platform (new, optional, array of strings / string): the platform(s) that this release is relevant for
this could also be extended in the future so that the user could select the platforms from checkboxes e.g
minVersion (new, optional, string): min version of the app that this release is relevant for
maxVersion (new, optional, string): max version of the app that this release is relevant for
isOverTheAirRelease (new, boolean): filter to hide these versions in the "Versions" tab
then when such a "over the air" Version is generated, we could just use a UUID as tag name so they are always unique. Using the graphql API, we could then fetch all the over the air versions and select the one which is meant for the app in the middle layer. For me, this whole part would not be part of accent as there is a lot of specific business logic.
Implementation
I would be willing to implement most of this myself also with the help of an external developer. But before I invest time in this, I would like to know if in general you would be open for such a change or if we should rather find another approach to this problem.
The text was updated successfully, but these errors were encountered:
I wanted to take a moment to express my appreciation for accent. It really is an awesome tool which regularly makes my day a lot easier (especially the extended activity log and the comments).
Idea
In order to migrate the last remaining projects to accent, we built a "middle layer" to enable the delivery of "over the air" updates to applications where the release process takes quite long or sometimes is even impossible (iOS apps for example). The most complex part is already solved by accent with the "versions" functionality. In order to now know which app version should get which versions of the translation, I just established a rather cumbersome naming scheme. Here is an example:
I'm just using semver ranges and prefix it with the platform (I share translations between both native codebases). This works quite well but also has some limitations and is quite error prone.
To support this "over the air" use case and make it more robust, an extension of the "Version" model would be needed. The following would by my idea:
then when such a "over the air" Version is generated, we could just use a UUID as tag name so they are always unique. Using the graphql API, we could then fetch all the over the air versions and select the one which is meant for the app in the middle layer. For me, this whole part would not be part of accent as there is a lot of specific business logic.
Implementation
I would be willing to implement most of this myself also with the help of an external developer. But before I invest time in this, I would like to know if in general you would be open for such a change or if we should rather find another approach to this problem.
The text was updated successfully, but these errors were encountered: