4 ms·

You can see my top-level comment for more info, but we wrote a very quick and dirty UI to manage the XML localizations that allows "forking" a language into a n

You can see my top-level comment for more info, but we wrote a very quick and dirty UI to manage the XML localizations that allows "forking" a language into a new localization and showing outdated or missing localization strings. I don't think a single person that contributed a translation was actually a developer, but I've had no complaints about it being difficult to follow in the going-on-twenty-years since its release! https://neosmart.net/forums/threads/translations-to-other-languages.696/ https://neosmart.net/forums/threads/translations-to-other-la...

svantex 2y ago
Nice - but very special purpose from what I can gather. I've done a few custom solutions myself over the years, but that's exactly what I'm trying to get away from. I want to write code that does cool stuff for the users of my apps, not code that does cool stuff to make translations possible - someone else can do that cool stuff ;-) where I'm the "user".
- ComputerGuru 2y ago
  Thanks. Not actually really special purpose. One-click import from any SWF project, though no easy WPF/XAML sdk for lack of motivation. The GUI is fully app agnostic.
  - svantex 2y ago
    Ok, maybe I was to quick to judge, I didn't spend enough time studying it. I looked at some screen shots, and it seemed like the translation tool knew things about the app, but I was apparently mistaken. Sorry.
    - ComputerGuru 2y ago
      No problem. The tool loads a directory of xml files; each file is rendered as a tab in the translation GUI. The framework exports the strings from each SWF form as a separate xml file into a directory that matches the native locale’s identifier (eg en-US) and gives it a friendly name based off the form’s title/caption and/or file name. So the end result is a naturally user-friendly approach to translation instead of having all the apps strings dumped together into one PO file as is the norm, and translators can reference the app they are translating’s UI as they methodically translate a component at a time.
      - svantex 2y ago
        Nice!

svantex 2y ago

Nice - but very special purpose from what I can gather. I've done a few custom solutions myself over the years, but that's exactly what I'm trying to get away from. I want to write code that does cool stuff for the users of my apps, not code that does cool stuff to make translations possible - someone else can do that cool stuff ;-) where I'm the "user".

ComputerGuru 2y ago
Thanks. Not actually really special purpose. One-click import from any SWF project, though no easy WPF/XAML sdk for lack of motivation. The GUI is fully app agnostic.
- svantex 2y ago
  Ok, maybe I was to quick to judge, I didn't spend enough time studying it. I looked at some screen shots, and it seemed like the translation tool knew things about the app, but I was apparently mistaken. Sorry.
  - ComputerGuru 2y ago
    No problem. The tool loads a directory of xml files; each file is rendered as a tab in the translation GUI. The framework exports the strings from each SWF form as a separate xml file into a directory that matches the native locale’s identifier (eg en-US) and gives it a friendly name based off the form’s title/caption and/or file name. So the end result is a naturally user-friendly approach to translation instead of having all the apps strings dumped together into one PO file as is the norm, and translators can reference the app they are translating’s UI as they methodically translate a component at a time.
    - svantex 2y ago
      Nice!