Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Web GUI for Translators #5

Open
joeblew99 opened this issue Dec 5, 2016 · 18 comments
Open

Web GUI for Translators #5

joeblew99 opened this issue Dec 5, 2016 · 18 comments
Labels
enhancement help wanted

Comments

@joeblew99
Copy link

I knwo google sheets is so so basic, but i saw another project doing it and its not half bad.

see here:
https://github.com/jgraph/draw.io/wiki/Translations

  • This is actually a great way to do it, mostly because Translators DONT have to screw around with git.
  • I can probably write a little tool to keep master in sync with the spreadsheet.
    • Does a Diff between what the code EN trans are and whats in the google sheet.
      • Red for removed from Git
      • Green for added from Git.
      • Translators can then sort by the Red, Gree and their language to see the exact work to be done.

I think there are some decent tools for talking to google sheets from golang.
https://developers.google.com/sheets/quickstart/go

  • It looks capable enough..
@deankarn
Copy link
Contributor

deankarn commented Dec 5, 2016

Hey @joeblew99

Yes it does look promising, I do however have a multi-step plan to do this sort of thing already, I just can't find the time to work on it lately.

My long term plan is to create another package that will use universal-translator that you can add, edit, remove translators and also manage all of your translations by locale through an http interface/site.

  1. I need to make some minor non-breaking changes to universal-translator to allow thread/goroutine safety to the adding, updating and removing os translators/translations.

  2. Add a few more safety checks to the VerifyTranslations() methods to ensure no locale is missing a translation that another may have.(so can't check in/save changes until all locales your site supports have the new translation.

  3. Build the new package, add accessor methods for retrieving translations added through the http interface and stored in say boltdb(will make a pluggable storage system so anyone can store however they want)

I was actually working on a solution to locales tests first because without it universal-translator is just a fancy map.You had given me the idea for in the locales package go-playground/locales#1 (comment)

I started creating a site that I will host publicly and people can select a locale, see all of the l10n translations and be able to verify correct one and submit corrections to ones they deem incorrect.

right now it just displays the translations based on selected locale(only two while testing), I have to work on the UI and storage for submitted responses. The project can be found here

I hope to get to this sometime in 2017, but like I said I'm so busy it's hard to make any headway; I would be very grateful for any help on creation of the UI to my end goal, or even the locale-site project.

@joeblew99
Copy link
Author

joeblew99 commented Dec 5, 2016 •
edited
Loading

Hey Joey,

I pulled the code and ran it, so i can see where its at.

i am in the middle of a project and not on the beach as it were, so cant spare much time on the GUI.
But one thing i noticed is that your using a postback architecture, which i suspect is going to be horrible to use. Why not make a SPA (single page app).

Check this out !!
https://github.com/mh-cbon/mdl-go-components
Its really nice visually and to work with as a golang programmer.
In the Demo folder, make sure you go into the static folder and do a npm install
then just main.go

Now have a look at chip-autocomplete.
Its rendering the Front end, and the wiring up the backend nicely.
i think its perfect for your project because its not too big.

I also had a bit of a brain wave about his code.
I was trying to work out how best to make much bigger apps, with out it getting too hairy.
I think i have a really good solution (which i suggested to him).
On a page with lots of components your going to have lots of postbacks, and then your ging to also want to update other parts of the page as a result of one part changing.
So we use a Microservice Pub / Sub pattern using events.
when a post happens down onto a component that component MUST publish the Event globally.
All other components on that page can subscribe to that event and react as they see fit.
The only problem is that the 2nd component might need to push data up to the front end, and the code currently does not allow this because its a POST model.
What is needed is a RFC model, with any component being able to push up via websockets.

@deankarn
Copy link
Contributor

deankarn commented Dec 6, 2016

Thanks I'll take a look, in my experience writing one language from another ultimately never pans out as well as expected.

I would usually modularise a route, page, rendering....into a single component and hook it into everything and then managing postbacks, errors, translations... Become easy to manage.

This is just a rough draft.

@joeblew99
Copy link
Author

joeblew99 commented Dec 6, 2016 via email •
edited
Loading

@deankarn
Copy link
Contributor

deankarn commented Dec 6, 2016

Thanks, when I've got the storage for the locales project complete I'll give you a shout.

Realistically not till next year, December is pretty much a wash for me.

@joeblew99
Copy link
Author

joeblew99 commented Dec 6, 2016 via email

@joeblew99 joeblew99 changed the title idea: Using google sheets for translators Web GUI for Translators Dec 6, 2016
@SCKelemen
Copy link
Contributor

What exactly do you want help with?

@deankarn
Copy link
Contributor

deankarn commented Feb 7, 2017

Hey @SCKelemen

It's really just the UI/UX I need help with; I was getting some of the underpinning done before hand like:

  • A flat file format for import and export of translations(which is almost done, just writing tests)
  • writing the DB layer and API to be used by web application, which I will start soon.

After that I can add extra code generation and checks.

The UI should be pretty straight forward I want the ability to:

  • Add locales you want to add translations for
  • Ability to group translations for purposes such as searching or viewing a single pages transitions eg. The homepage.
  • Add translations, all 4 types, text, Cardinal, Ordinal and Range
  • ability to add or modify translations for all locales in a single view.

Any help or thoughts on layout would be appreciated 😄

@ghost
Copy link

ghost commented Apr 16, 2018

I have a suggestion regarding the GUI.

Use grpc and gopherjs.
It's a superior way to build a 100 % system with golang.

https://github.com/improbable-eng/grpc-web

Good example to get started:
https://github.com/johanbrandhorst/protobuf

I have used this for a few tooling projects.

You can build a web GUI and a CLI all using grpc for all comms.

It's quite well tested now too.

This will also make it easy to hook into Google translate using grpc also for machine translations.

Also congrats Joey on all of this. It's an amazing body of work. It's amazing that the Google team have not picked this up actually.
I embed this library into other projects like gopherjs and flutter because you get i18n all from one system in golang and so get all the same translation and currency logic everywhere ( servers, desktops, mobiles ).

I am hoping to write a plug-in for flutter to hook into this code also. It's pretty easy and a few other gophers are doing the same hooking up between flutter and golang. But no freaking time.

@deankarn
Copy link
Contributor

Thanks, happy that it has been of help! Unfortunately, I also have no time to work on this project right now.

I wanted to build out the GUI and interactions with other services like google translate and such, but I can't spare the time; I'm leaving it up to the community to build packages on top of this but will be able to assist in adding/exposing what is needed from this library.

@ghost
Copy link

ghost commented Apr 16, 2018 via email

@SCKelemen
Copy link
Contributor

If this is something we really want to do, I can spin up a webui. If you guys have an existing API, can you give me whatever reference is available? If not, I can just do my own thing, and add it in a new package here.

@deankarn
Copy link
Contributor

Thanks @SCKelemen So before we can even make an API I have to do a few things.

  1. I have to make small breaking changes, iirc, to ensure that the backend storage is properly thread safe to enable updating on the fly.
  2. I will make/ensure the backend storage is configurable.

After that I can create the API http layer; I'd also like to stick with http right now and forget about GRPC, it will only complicate things at this stage.

After that all sorts of external translators can be added.

Having said all that it's going to take me 2-3 weeks to get to making these changes as work is keeping me busy, I'm moving in just over a week and other projects are consuming my time, but I will try to sneak in some time to work on it as best I can.

Does that seam like a reasonable plan?

@ghost
Copy link

ghost commented Apr 18, 2018 via email

@SCKelemen
Copy link
Contributor

Yeah, no gRPC. Just restful HTTP or GraphQL if you must. Also, I don't know anything about this GopherJS thing, so is a simple react application acceptable? Preferably using TypeScript?

@ghost
Copy link

ghost commented Apr 18, 2018 via email

@ghost
Copy link

ghost commented Jan 16, 2019

Can this be picked up again.

I can help build a GUI as I have been doing many on top of golang.

The question I have is what it needs to do ?

Maybe some ideas are :

  1. General parse to check the state of the go files, reaching into the JSON translation files to make sure all keys between the two match.

2 a runner.
Presuming you have done the translation then run a GUI that does data binding between html files and the JSON.
The GUI then allows you to switch locales to see things are visually working.

  1. Workflow
  • step 1 as above to parse the state
  • make a new language translation file based on the master.
  • check all cross language JSON files have values for all the keys. This can be used by human and machine translators. For humans we can show them in the GUI with a basic JSON editor.
  • check i10n aspects too.

Architecturally I would like to add visual support for machine translators. A standard driver API to be used. A cache so that any machine translation is not used again. Also when a human overrides a name that was machine translated it records that. All the above would allow a developer to be able to start a full translation at any time in their development and only a tally hit a machine translation service for changed keys. Saves a ton of money.

I don't think building this workflow is that much work.
I think a basic cli would be the first step to check the orkflow and logic.
Then layer a GUI on top.
The cli and GUI would talk to the same translator core service.

@deanishe
Copy link

Rather than write a GUI, would it not make more sense to export the translations to a common CAT format like XLIFF, so translators can use their existing tools and glossaries/translation memories?

CAT software is fairly sophisticated and translating is a lot more difficult and especially time-consuming without it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement help wanted
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@deanishe @SCKelemen @deankarn @joeblew99