1. indifex
  2. transifex-commonpool
  3. Issues
Issue #11 wontfix

Jetpack versioning

Zibi Braniecki
created an issue

This is more of a discussion opener, than a bug.

We have to start thinking about the jetpack update scenario. It basically means for us that a jetpack author will push a new version of the jetpack that we already have tracked (= same jetpackID).

Now, what we need to do here is to distinguish between versions of jetpacks and entities used by given versions. We also want to reuse as much as possible.

One particular complication here is the per-line exception as it may change the exact line number value in between versions.

fim: do you have any guess on what we could try to do here? What approach fits transifex? I'm worried that we will have to slightly modify the models and it makes sense to have a Jetpack model for now (with its versions). I'm also not sure how it'll translate onto transifex vocabulary.

Comments (4)

  1. Seraphim Mellos

    In the original schema there was no Jetpack model because it seemed simpler and it fitted our workflow. Now, if we add versioning support for jetpacks it may be needed that we move jetpacks to their own models but this doesn't solve all the issues.

    My opinion is that we should use something as a jetpack identifier that's the jetpack id and the version combined so we'd treat each version of a jetpack as a different jetpack. This way we can add per version exceptions without making too many changes.

    But still this can be done without creating separate models for the jetpacks but by keeping the existing db schema and just saving the jetpack name and the jetpack_id+jetpack_version as the jetpack identifier in the database.

  2. Zibi Braniecki reporter

    It could be possible, but I predict it'll cause us more headache later as we add more features and extend the maintenance features of the tool.

    In particular, we will need a specific glue code for translation migration between versions. Probably with some UI magic - especially for per-line exceptions that may be threat like patch hunks.

    I suggest going the longer way and adding Jetpack and Version models, some glue code for automatic translation migration between versions and some more automagic solution for per-line translations. For example: If an entity is the same, file is the same, and the line is less than +/- 100 off the original one, migrate automatically.

    Later, if this will not be enough, we may want to add some UI for localizers to allow them to pick which entities to migrate, and which not.

  3. Seraphim Mellos

    Hey gandalf,

    I've started to work on this and I got most of the core stuff working. I need to work out the details as well and I need some more information. For example, we need something to identify each jetpack which I guess is the jetpack id. But if we decide to provide jetpack versioning we need to construct a string from the jetpack id and the version number.

    The problem with this is that if we rely on these attributes and only check those for inconsistencies, we may have issues in the UI in cases where two Jetapacks will have different IDs and the same name for example since we only display on the UI the Jetpack name. Also, the same applies somewhat on the API so if we want to do filtering based on jetpacks we need to know on what attribute the filtering should be based on. Furthermore, in the API where we list the exceptions for each jetpack, we need to have a unique id per jetpack to use in there as well (probably the jetpack id + the version?).

    To decide all these I need to know what is unique in each jetpack (name, id etc) and how exactly you want transifex to behave on all jetpack based operations.

  4. Log in to comment