Localization
-
Go ahead and put it in Mantis. That's exciting!
-
@toggledbits I've done a (test) Swedish translation for MSR, I don't want/need a translated version, but I had the time and perhaps some future users would find it useful
I noticed it's a bit early in the process to go live with systemwide localizations so no github in place yet, do you want input on this now or should we wait a few releases? considering it may be low priority issues.
If so, do you want feedback here or in mantis? -
This is so cool. I don't even have the words, honestly. There are very personal feelings at work here. I'll just say I come from a world family, so seeing Reactor in a language other than English adds a connection for me that I have long wanted to see. Thank you for taking the time to do this.
Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
This is so cool. I don't even have the words, honestly. There are very personal feelings at work here. I'll just say I come from a world family, so seeing Reactor in a language other than English adds a connection for me that I have long wanted to see. Thank you for taking the time to do this.
@toggledbits Well you made it fairly easy, all it needs is a little bit of time and correct wordings for the appropriate places, so thank you.
-
This is so cool. I don't even have the words, honestly. There are very personal feelings at work here. I'll just say I come from a world family, so seeing Reactor in a language other than English adds a connection for me that I have long wanted to see. Thank you for taking the time to do this.
@toggledbits According to the documentation for localization:
"You may, at your option, contribute your language file to be included with future builds of Reactor as an add-on ... We will simply pull your latest language file from your Github repository directly when and as needed during builds..."
Will this hold back the release of a new build, waiting for translators to update their repos with new versions matching the new build?
-
This is all so new, I hadn't really thought about it, but here's my first reaction to it:
- I would not delay a latest build, as these are not scheduled, and sometimes have urgency.
- I would delay a numbered release (e.g. 1.0.1, etc.). But, my plan and practice so far has been to derive these from prior latest builds that have proven stable, so I can factor in the necessary changes at that point and wait for them. This may require a bit of additional configuration management on my part, but I can plan the timing of the release, and give everyone predictable schedules.
Going forward, I think there are two practices that we will need to follow to give the best/longest compatibility:
- Strings are not removed from the translation files when later versions disuse them, at least, not for a very long time. Rather, they can perhaps be moved to the bottom of the file under a comment
# Strings not used as of 21267(for example) to keep them organized but still present. In this way, a 22044 translation file would still work well for 21267 or versions prior, because it still contains the old strings. At some major revision (2.0) we can clean house and remove the old strings. We've removed a few already; I won't ask you to remove any more, I'll just call them out as "disused." - Strings will not change their keys, use, or meaning. If a changes in these ways, a new string (or tag) will be created for the purpose, and the old version can go on the list of old/disused strings. This should help ensure that 21267 and 22044 use a string in the same way, and the translations are valid in both. So, for example, the
1:Tchange I just asked you to make will never be repeated; it was the first and last such request, and we'll do it by replacement going forward.
Any thoughts or recommendations you have about all this are more than welcome. I've done many product localizations from the original engineering side. What I haven't done is worked with language teams on localized builds thereafter -- that has always ended up going to other departments and other companies in other countries, and handled weeks or months after my work has been packaged and released in the US. So, I don't have any experience at policies and procedures that work in helping you maintain the work. I have a good imagination, but it's a bit of "the tail wagging the dog" as we say here, so I'm eager to have you tell me what you think should be done. What we're doing now is only my first guess to see what happens to get it rolling.
Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
This is all so new, I hadn't really thought about it, but here's my first reaction to it:
- I would not delay a latest build, as these are not scheduled, and sometimes have urgency.
- I would delay a numbered release (e.g. 1.0.1, etc.). But, my plan and practice so far has been to derive these from prior latest builds that have proven stable, so I can factor in the necessary changes at that point and wait for them. This may require a bit of additional configuration management on my part, but I can plan the timing of the release, and give everyone predictable schedules.
Going forward, I think there are two practices that we will need to follow to give the best/longest compatibility:
- Strings are not removed from the translation files when later versions disuse them, at least, not for a very long time. Rather, they can perhaps be moved to the bottom of the file under a comment
# Strings not used as of 21267(for example) to keep them organized but still present. In this way, a 22044 translation file would still work well for 21267 or versions prior, because it still contains the old strings. At some major revision (2.0) we can clean house and remove the old strings. We've removed a few already; I won't ask you to remove any more, I'll just call them out as "disused." - Strings will not change their keys, use, or meaning. If a changes in these ways, a new string (or tag) will be created for the purpose, and the old version can go on the list of old/disused strings. This should help ensure that 21267 and 22044 use a string in the same way, and the translations are valid in both. So, for example, the
1:Tchange I just asked you to make will never be repeated; it was the first and last such request, and we'll do it by replacement going forward.
Any thoughts or recommendations you have about all this are more than welcome. I've done many product localizations from the original engineering side. What I haven't done is worked with language teams on localized builds thereafter -- that has always ended up going to other departments and other companies in other countries, and handled weeks or months after my work has been packaged and released in the US. So, I don't have any experience at policies and procedures that work in helping you maintain the work. I have a good imagination, but it's a bit of "the tail wagging the dog" as we say here, so I'm eager to have you tell me what you think should be done. What we're doing now is only my first guess to see what happens to get it rolling.
@toggledbits I believe your suggestions for long term compatibility is spot on.
Considering this is new and we are running "latest" there will be frequent acceptable changes that demand translators/user actions for keeping things up to date.
As you say numbered releases should probably already have an updated file for localization and I really like the implementation of disused strings for backward compatibility. -
OK. I'm updating the docs with all of this. Keep the discoveries and suggestions coming!
-
T toggledbits locked this topic on
