Translations for plugins?

jiminy-billy-bob

Great idea!

Rich O Brien

What needs to happen?

driven

@rich o brien said:

What needs to happen?

my two pence...

Personally, I've been attempting to create a 'User Translation' mode for one my plugins, to try and figure out if a generic approach would be feasible for other author's plugins...

Primarily, I believe non-developer ' User Translations' need to be accomplished from within SU itself using at least 2 local WebDialogs and a cloud based index of contextually targeted words and phrases.

For simplicity, I'll refer to @tool, @trans, @index

@tool, can be either the tools wedDialog or toolbar re-presented in a webDialog

@trans, all user facing text on single lines, followed by an input box and action buttons. e.g. assist, accept, apply.

@index, I've been using Google Translate, but it could be a SCF or Trimble for the index.

In usage, the User selects 'Translate This Plugin' from a 'Help' menu item and selects a plugin.

@tool, opens showing what they would normally see, in it's default or previously adjusted format.

@trans, opens showing ALL User Facing text strings associated with the Plugin

@index, when called from a particular string, opens with an index of possible alternatives for a target language.

If accepted, @ trans is updated, @tool is updated to show as a preview.
If applied, a local copy of the modified file are created.

In an ideal world these accepted modifications would be fed back to @index for access by others.

To facilitate the finding of 'User Facing' strings, I have used lang_get %Q(string to translate) throughout all plugin files.

I think a good starting point is a repository of all the SketchUp native string files for all the supported languages and the ability to add additional terms and phrases.

more latter

john

Aerilius

An online translation management system exposes for each software package a list of translatable strings. Users work through the list of untranslated strings without obligation to "finish" 100% on their own. For each translatable string the system proposes similar strings from the already translated base.
The translation software generates from a completed language (or 70% completed) an output file that can be distributed with the software. A common output file format is .po (GNU gettext).
Usually such translation management systems are fully integrated with package management systems, ie. users receive translations with their software updates.

@rich o brien said:

What needs to happen?

We need to check out how to expose our translatable strings to a translation system, and how to get them out again.

SCF decides for and installs a translation management system
we developers would need to agree on a common format. I think the very large majority uses the same format ( "source"="target";) and it should be fairly simple to extend Pootle or another system to read and write these files.
with agreement of Trimble SketchUp, the system could be fed with SketchUp's translation strings to have good proposals (and to use a consistent vocabulary of technical terms).
developers upload their translatable strings to SCF, or (*****) SCF extracts them from an uploaded plugin package
developers include the resulting files in a plugin package, or (*****) SCF packages the translation files automatically into the plugin package, or SCF distributes them as a separate update to users.
(*****) eventually developers would need to agree on a common folder structure where translation files are located

Aerilius

@driven said:

a 'User Translation' mode for one my plugins

Fredo has worked on a translation tool via webdialog, and you too. Ideally we would be able to re-use existing systems that just need to be installed and avoid re-inventing as much as possible. Before we come to a comclusion or decision, it is important to collect all our experiences with our own efforts or with how professional translation systems work.

For now, we would best concentrate on a requirements analysis or suggestions for functional solutions, and not dive too deep into technical solutions.

@driven said:

Primarily, I believe non-developer 'User Translations' need to be accomplished from within SU itself using at least 2 local WebDialogs and a cloud based index of contextually targeted words and phrases.

So if I understand right, your idea is a kind of "translation suite" installed on the client side (directly in context of SketchUp).
My thought of an online system was that these are readily available, and the possible translator base would be all the SCF members and not limited to those who have the translation plugin installed.

But you have a very important point here:
Translators need to have an idea of the context where a translated string appears.
Traditionally this is often achieved by developer/translator comments, but ideally one could dream of a WYSIWYG editor, where the software's GUI elements have editable text. This might be available in established GUI toolkits/IDEs. But for SketchUp it is complicated because of its API's very diverse and dispersed UI elements (menu, toolbar, tooltips, OpenGL text, status bar, WebDialogs with complicated skp bridge). We are neither GUI framework developers nor IDE developers, so for the beginning I wouldn't see it in scope of what we could achieve.

Rich O Brien

You can consider that the management system will be implemented on SCF when you need it or if you need it.

I can't speak for Trimble or SketchUp.

But we'll deliver whatever resources you guys decide on.

Dan Rathbun

FYI: http://translate.google.com/toolkit/docupload?hl=en
Notice under "Other" that the types include ".po" and ".strings" files.

If you have a Google Gmail account, there is a built-in interface that lets you create, edit, collaborate and share translation glossaries.
Sign IN to your Google account, then click here to enter the toolkit interface

They are simply UTF-8 encoded CSV tables. See:
Custom Glossary Format

Using translation glossaries

More about dictionaries and glossaries

Dan Rathbun

From the user perspective:

(1) Other than downloading & installing a translation manager library/plugin, translating GUI strings should be transparent to the user. (There could be a collaborate / help menu item that allows the user to help translate phrases & words for various glossaries.)

(2) The translation features would need to also work when "offline". This means glossaries need to be downloaded into a local archive. Updating glossary files should be transparent when possible, but could also be manual if the workstation is only connected to the web to do updates, periodically.

Dan Rathbun

From the Developer perspective:

**(1)**Adding automatic translation support to a plugin sub-module should be done in the normal "Ruby-ish" way of including a mixin module that has the desired functionality exposed in methods, attributes and constants that are added to the author's plugin module.
Ex:

module Author

  module ThisPlugin
  
    include(SCF;;AutoTranslate)

    ## plugin's code 

  end # plugin sub-module

end # author's toplevel namespace module

(2) The lookup method name should be short and simple. I have been using the method name say and when I implement a string lookup hash, I often reference it as @say, and the say() getter method is set to retrieve elements from the hash.
Ex:
answer = UI::messagebox( say("Save model changes?"), MB_YESNO )

If you prefer some longer name, you can alias the say method:
alias_method(:lang_get,:say)

caronte01

Hi all,

I would volunteer to help manually translate some plugins to spanish. Ruby developers give a loooot to us regular sketchup users, so helping with things like this is the least we can do. Those automatic translations are really really bad, esp. for technical terms.

If there is a central topic, where developers ask for volunteers to translate their plugins, maybe by plugin, or by language, count me in!

Santiago

tt_su

A unified translation system would be nice. I for once would prefer if there was one dialog to set up a list of preferred languages, similar to how browsers offer preferred languages for website.

But are you guys talking about a system to upload a translation specific to each extension or to generate a pool of generic translations. Generic translations is very tricky, without the context of what it's related to it's easy to get it wrong. (Which is why automated translation often fails miserably.)

Aerilius

The original suggestion was to make it easy for all SketchUcation members to translate each of our plugins to their own languages (via an online-hosted translation management system like it is used for OpenSource software, maybe you've seen it at Mozilla or Launchpad). It is much more efficient and has a low entry barrier, and no single user is forced to do 100% of the work. Translating together is fast and fun.

@tt_su said:

But are you guys talking about a system to upload a translation specific to each extension or to generate a pool of generic translations.

Each plugin would be translated individually, with based on .strings files as you already have, but hosted online (like you can host code in git/mercurial/bazar).
While such systems often feature a translation pool and bindings to machine translators, that is only as help and does not replace human-made quality translations.

Now in this context there are also other ideas (that we could of course discuss also, maybe even in their own topics):
• unified translation framework for Ruby plugins (like LangHandler?). If LangHandler actually was good enough to replace my own Translate library, and if it was backported and available on all SketchUp installations, that would be best.
• developing a translation tool integrated in SketchUp
• SketchUp preference for language priority (How many secondary/third languages would people set up? Could this be achieved inside SketchUp or its API?)

Dan Rathbun

@aerilius said:

Each plugin would be translated individually, with based on .strings files as you already have, but hosted online (like you can host code in git/mercurial/bazar).

I'm out. I do not use .strings files, nor LanguageHandler specifically because it's fixes are not backported. (And they never will be, because backporting is against the SketchUp Dev Team's religion.)