Setting up Lyra for 666a

[henrycatalinismith]

I'm curious about setting up a Lyra config for my other project, 666a. I think it might be an interesting way to explore ways of making Lyra more flexible and/or easier to set up.

Here's what I've got so far. Let's assume I only want to get en.yml, sv.yml and ar.yml running, ignoring the other stuff in config/locales/*.yml with the devise. prefix as that issue is covered by #112.

Config files

zetkin/lyra/config/projects.yaml

projects:

  - name: 666a
    repo_path: /Users/henrycatalinismith/666a.se
    base_branch: lyra
    project_path: .
    owner: 666ase
    repo: 666a
    github_token: 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
    messages:
      format: ts
      path: config/locales
    translations:
      path: config/locales

666ase/666a/lyra.yml

projects:
  - languages:
      - sv
      - en
      - ar
    messages:
      format: ts
      path: config/locales
    path: .
    translations:
      path: config/locales

Outcome

http://localhost:3000/projects/666a

http://localhost:3000/projects/666a/en

[henrycatalinismith]

lol I'm so good at computers

[henrycatalinismith]

Creating this has inspired me to check out Rails-based alternatives to Lyra. The Rails community has a good tradition of creating little open source apps for common things like this. For example, I'm using rails_admin and flipper in 666a already. Here's some of what I've found in terms of Rails projects that implement some kind of translation string management app.

• https://github.com/westonganger/rails_i18n_manager
• https://github.com/tolk/tolk
• https://github.com/mose/rails-i18nterface
• https://github.com/prograils/lit
• https://github.com/amberbit/translator
• https://github.com/jtoy/sanbit_translations
• https://github.com/Sage/i18n_yaml_editor
• https://github.com/fabiolnm/rails-dictionary
• https://github.com/BrucePerens/i18n-edit
• https://github.com/netmilk/i18n_locale_editor

Came as a bit of a surprise that there isn't already something polished and complete and actively maintained and popular. It's clear from the number of attempts that lots of people see a need for this kind of app. I wonder what's been getting in the way of anyone solving this in a way that leads to the kind of broad adoption where a community forms around the project.

[henrycatalinismith]

I've been setting up Transifex. I added a transifex.yml and ran through their onboarding. Here's a quick visual summary of it.

Was a little fiddly to send the pull requests. No "Send Pull Request" button in the translate UI. Had to dig around in the settings for the GitHub integration. But I did find one and press it!

henrycatalinismith/666a.se#72
henrycatalinismith/666a.se#73

It's a shame it's gone so hog wild with the yaml there. I'm going to have to manually checkout those PRs and see what effect they have cos I suspect adding empty strings like that will have broken the "fall back to English when a translation is missing" behaviour of Rails i18n.

Very interesting though. Lots for this project to learn from I think.

[WULCAN]

Configuration for 666a

The projects.yaml in the issue description includes properties messages and translations. Lyra does not look for those properties in projects.yaml so they will be ignored.

The lyra.yml in the issue description configures ts as message format. That format is meant for the messageId system in app.zetkin.org. As far as I can tell, 666a does not use that system. Lyra tries to support projects like 666a too but has to be configured with message format yaml.

With yaml format for messages, Lyra doesn’t support editing the English translation, as that is seen as the default messages, and the source of truth of the messages to be translated. The issue description’s lyra.yml includes en in the list of languages to be translated so that should be removed too. I don’t really know how Lyra will break if you try translate the English default messages so it might be fun to hack around with, but it’s not supported.

Documentation is clearly lacking here. There's an idea of moving away from configuration files towards an admin UI. That's going to take a while so I don't think it would be a waste of time writing a little more on configuration in the README first.

Missing error handling

Your outcome screenshots show that Lyra is lacking error handling, especially for this case. I am guessing there are a lot of error handling we can add on multiple levels but it might be more cost efficient to make it easier to configure Lyra as Lyra expects to be configured.

Security tokens

You are not the first to accidentally publish security tokens. I think we can conclude that Lyra encourages this kind of mistake and it's something we should prioritise fixing. Lyra administrators are not always going to be so lucky that GitHub invalidates their published credentials.

Other Translation Management Systems

That's a lot of ruby projects to review. Do I understand you correctly that you found none of them polished, complete, actively maintained and popular?

Anyway, it would be good to review them all before reinventing their bugs in Lyra. =)

There's a few more projects listed at https://formatjs.io/docs/getting-started/message-extraction#translation-management-system-tms-integration

Clobbering translation files

Lyra has this kind problem too as it updates translation files by serialising a representation of them as a replacement for the original. It seems like a pretty hard problem to solve well but I have a couple of ideas:

• Many parsers can report offsets in the file for parsed segments. We could use those offsets to just replace the changed part.
• We could probably hack together some detection for indentation and other styles, and then just apply those rules to the serialiser. That might be good enough to make even the first pull requests small.