Translators tools WG

Participants: Lauri A, Lauri C, Chunxiang, Inari

User interface

• We'll aim to use already existing stuff as much as possible: Krasimir's editor as a base, decorate that.
• User authorization; discussed options such as
  • Google authorization module
  • LDAP
  • OpenID
  • LauriC will look at translation project management websites (for example Project Open) to see if they have something to offer for us.
  • Discussed about usability; we'd like to offer a possibility to use gmail or facebook or whatever account if you're afraid of technology and think it's too complicated otherwise, or create your own account if you're afraid of selling your soul to big corporations.
• Lexicon management
  • We don't want to have another translation memory. Not GF-like to remember strings.
  • Modifying lexicon means modifying grammar; lexicon is just a name for leaf productions. Could example-based grammar writing also allow the user to modify idioms?
  • Hierarchy of demands, from the minimum to the ideal:
    • A complaint button, "this is wrong please fix it", and the message goes to a grammar writer who is actually a person.
    • Correct an error by inserting stuff manually, recompile the grammar and then it works (supposing the user did the right thing in the first place).
    • Error correction on the fly, corrections straight to PGF, no need for recompilation, user doesn't even need to know anything about PGF and compilation
  • Tabular editor, new features:
    • Implement "search for similar terms" query, and allow going higher up the tree
    • Modify terms in the row
    • Add new rows
    • Delete rows
    • By clicking a term, make it appear in the text in the editor tab
    • If term has many translations in one language, show only 1 row and add an expand button in the slot for the language that has the multiple translations

Back-end

• LauriC has added a term tab to Krasimir's editor. Currently just a separate tab, no connection to the editor tab, but we should be working on it.
• We have PGF stuff on our own server. Everything works fine.
• The code for document manager is in darcs, but it's not working and there is no documentation.
• Chunxiang's tabular editor: ideal workflow should be like this
  • Java backend: gets access to SPARQL endpoint, does the quer(y|ies)
  • JavaScript frontend: outputs the results nicely, allows user to go up or down in a hierarchy (which means more SPARQL queries done by the Java backend); allows user to delete concepts, add concepts and their translations and modify translations fetched from the ontology. All this information is stored in some place, probably in JSON.
  • Java backend: gets access to the storage, outputs nice GF files. Probably not touching existing GF files, but adding new modules: add new abstract syntax, and concrete syntaxes for every language user has chosen. Add to the human-made LexiconXyz.gf the automatically created file only as an import.
    • where to get the information about abstract types? One solution: the querying is connected to the existing grammar; not just saying "I want flowers", but "I want all things similar to this pizza", and if pizza's abstract syntax type is Kind, we'll know that all things returned by the query will be also of the type Kind.
  • Open question: how to modify the PGF? But anyway, even if PGF is modified, we should add all changes to gf files as well, because a human might want to modify the grammar later and recompile to new PGF. LauriA interested to work on it.