Web GUI for Translators

[joeblew99]

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]

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 https://github.com/go-playground/locales/issues/1#issuecomment-259114196

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]

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]

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]

I see your point. Page knows all components so it can control it all. I was over baking the cake :)

Your approach will work with that MDL library, because it does not assume much at all.

If you do then, then i am up for helping on this.

Joe

[deankarn]

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]

thats fine. Feel free to buzz me when your ready. Its a nice project and worth doing.

cheers

Joe

On Tue, Dec 6, 2016 at 3:07 AM Dean Karn [email protected] wrote:

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.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/go-playground/universal-translator/issues/5#issuecomment-265039602, or mute the thread https://github.com/notifications/unsubscribe-auth/ALcac_ZOgTf-0PzCmbNn3BMqXtxUXLH4ks5rFMNGgaJpZM4LEw6v .

[SCKelemen]

What exactly do you want help with?

[deankarn]

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 :smile:

[ghost]

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]

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]

no worries i think i can get something going pretty quick. Will start with a CLI and get the interaction right and then do a web GUI. Will update you with how i go.

As far as Google ML translate thats easy.

On Mon, 16 Apr 2018 at 17:12 Dean Karn [email protected] wrote:

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.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/go-playground/universal-translator/issues/5#issuecomment-381640058, or mute the thread https://github.com/notifications/unsubscribe-auth/ATuCwqPd4zxdzyEEZu6sWxafJWxRaQ7Fks5tpLT0gaJpZM4LEw6v .

[SCKelemen]

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]

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]

Sounds good.

Might i offer some advice. Since your ready now to do the web GUI and the golang API is not ready, you can do the Web GUI without the API for now. Just use a JSON dataset for what makes your GUI work for now.

Then once the API is ready we can refactor it to the golang API.

On Wed, 18 Apr 2018 at 15:45 Dean Karn [email protected] wrote:

Thanks @SCKelemen https://github.com/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?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/go-playground/universal-translator/issues/5#issuecomment-382391686, or mute the thread https://github.com/notifications/unsubscribe-auth/ATuCwtf7zd9muy0SY62Gxgxeog1ie7dXks5tp0OSgaJpZM4LEw6v .

[SCKelemen]

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]

up to the maintainer.....

On Wed, 18 Apr 2018 at 19:41 Samuel Kelemen [email protected] wrote:

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?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/go-playground/universal-translator/issues/5#issuecomment-382469902, or mute the thread https://github.com/notifications/unsubscribe-auth/ATuCwu4pJyuXIjkEaOA8rLVvuu4rL2Tgks5tp3q-gaJpZM4LEw6v .

[ghost]

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.

3. 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]

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.