Deleting transifex resources

[joekur]

I notice you have an auto_delete_resources flag, but it looks like this is specific to the multi-branch workflow, in which a deleted branch will delete all of its respectively-tagged resources in transifex. I'm wondering about the use case of when you delete a translation file in master (or whatever main branch), or if you rename that resource (essentially a delete and an add). Have you put any thought into this workflow? At first thought it seems it may be somewhat complicated since I'm assuming that the .tx/config would get updated along with the deletion of the file, so your configuration would no longer know about that resource when you process the webhook.

The workflow might be more feasible if we were to implement what we've been thinking about for a large rails project with many separate yml and json translation files - being able to configure resources based on a file glob pattern. Eg if we could say any file matching /config/locales/**/en.yml should be treated as a translation file, and somehow map that to a programmatically to a resource name. This feature would of course be diverging from the functionality of the tx client, but I believe it would be very useful for the way we organize our app. This is a bit off topic my original question, but maybe such an auto-delete feature would only be possible with this second idea.

[camertron]

Hey @joekur, this isn't something I've given a lot of thought to but I can see how it could be useful. A glob pattern could even work on a per-branch basis, since the .tx/config file works that way now and resources are tagged/scoped by branch name. Deleting resources scares me a little bit, but hopefully anyone who makes use of that feature stores their translations in a translation memory. It probably wouldn't be too hard to support globbing in txgh, do you have any interest in taking a crack at it? I'm happy to help you get started if you're interested :)

Could you tell me a little more about your use case? Why do you have so many separate translation files?

[joekur]

We just have a large rails app. At some point having a single huge yml file was cumbersome so we split it up into multiple files - we don't have a completely consistent organization pattern but for example, generally each view and each data model has its own file. Our config looks like this: config.i18n.load_path += Dir[Rails.root.join('config', 'locales', '**', '*.yml')].

I would definitely like to spend some effort on this in the near future. Let me know if you have any thoughts on the format of the config.yml. Here's an example of what it could look like to get us thinking:

[project-slug.<**>-resource-slug]
source_file_glob = locales/**/en.yml
source_lang = en
type = YML
file_filter = locales/<**>/<lang>.yml

Another conceivable structure that may desire both a ** and a *

[project-slug.<**>-<*>-resource-slug]
source_file_glob = locales/en/**/*.yml
source_lang = en
type = YML
file_filter = locales/<lang>/<**>/<*>.yml

It seems like it would be difficult to allow any file glob at all, since in the end that needs to get mapped to both the translation file and the resource slug. I'll continue pondering on this..

[camertron]

Hmm... I didn't consider that the project and resource slugs will have to contain wildcards, that makes things significantly more challenging. As you mentioned, adding globs and wildcards also mean the .tx/config won't be compatible with the Transifex CLI client.

One thing you could do would be to write a script or rake task to generate the .tx/config. You could run it every time you create a new .yml file:

# lib/tasks/tx.rake

PROJECT_SLUG = "myapp"

namespace :tx do
  namespace :update_config do
    File.open('.tx/config', 'w+') do |f|
      # maybe write "[main]" section here

      Dir.glob(Rails.root.join('config', 'locales', '**', 'en.yml')).each do |yml_file|
        # assume top-level key is resource slug
        resource_slug = YAML.load_file(yml_file).keys.first

        f.write("[#{PROJECT_SLUG}.#{resource_slug}]\n")
        f.write("file_filter = #{File.join(File.dirname(yml_file), '<lang>.yml')}\n")
        f.write("source_file = #{yml_file}\n")
        f.write("source_lang = en\n")
        f.write("type = YML\n\n")
      end
    end
  end
end

We've found adding a new .yml file is pretty rare, so we haven't really run into this issue. How often do you guys add a new .yml file?

[joekur]

Yeah I'm considering a script to edit the config.yml as well. We have almost 600 separate translation files currently. I wouldn't be surprised if we were adding a few every week.

An added benefit of splitting these out is that we can get webhooks from transifex once a contextual "chunk" of translations have been completed, instead of waiting until the entire project is translated for a new language, or creating a commit for every separate translated string.

[camertron]

Wow ~600! So definitely something that should be managed programmatically! Do you currently have a Transifex resource for each .yml file?

[joekur]

Yeah, currently for that app we are running a home-brewed app pushing to transifex/github that of course handles the programmatic file glob matching. 1 file = 1 resource. But I'm running txgh now for our mobile apps, and looking to move our rails app over at some point as well to streamline everything.