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.

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

Added a view basic translation functions and translation file #137

Merged
merged 36 commits into from
Aug 16, 2018
Merged

Conversation

mjarkk
Copy link
Contributor

@mjarkk mjarkk commented Aug 13, 2018

What do you think of this way of translations?
Currently it doesn't auto detect the system language because i don't know how to detect that but the translation works when you change the language.English to language.Dutch

@jesseduffield
Copy link
Owner

Looks good to me! I've got a couple questions though:

Does this require the translation file to be sitting in the user's computer at runtime, or is it baked into the binary at compile time? If it's the former, I'm not sure how best to install that. If the user installs via go-get, that's easy, but it's harder for e.g. direct download from the binary. I'm not sure what the general pattern is for non-english speakers when it comes to these things. Is there usually a translation file that is available alongside the release for the user to download and store somewhere? Or is there some other approach

@ponsfrilus
Copy link
Contributor

ponsfrilus commented Aug 13, 2018

IMHO these should be translated too, as well as the error messages.

@mjarkk
Copy link
Contributor Author

mjarkk commented Aug 13, 2018

@jesseduffield Most programs have all translations in the binary by default.
For the Toml files they are not included in the binary so that's not an option anymore
I saw that go-i18n also has a view functions to add translations directly inside the code so that's probably the solution for the Toml files.
Another thing that may work is to use separate Go files that just exports that config file as a string but that would break the syntax highlighting for whats inside that string.

@ponsfrilus Thx for the suggestions i'll see what i can do

@jesseduffield
Copy link
Owner

@mjarkk this is fantastic work man I really appreciate the effort. I've just merged a big refactor PR #132 into master, meaning you might need to shuffle some things around to make it mergeable. It's only the first step of the refactor process so it's got some flaws but it removes things like global constants and generally improves the structure of the project. Let me know if you need any help merging with the new master branch

@mjarkk
Copy link
Contributor Author

mjarkk commented Aug 14, 2018

I have fixed all the merge conflicts

pkg/i18n/i18n.go Outdated
@@ -9,12 +9,16 @@ import (
// the function to setup the localizer
func getlocalizer() *i18n.Localizer {

// detect the user's language
userLang, _ := jibber_jabber.DetectLanguage()
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NIIIICE!

@jesseduffield
Copy link
Owner

@mjarkk I've just pulled down this branch and have made a couple of changes so that it conforms to the project structure, namely attaching the localizer to the App and Gui structs so that we're not depending on global variables at runtime. Otherwise fantastic job! I'll push my changes now

@jesseduffield
Copy link
Owner

I've just realised that we need localization for error messages too. I think that's fixed by just attaching them to the gui as well which I can make a start on now

@jesseduffield
Copy link
Owner

jesseduffield commented Aug 14, 2018

I've just had to do some reading because I considered just switching back to the package-scoped localizer variable that was there initially so that we can still define our errors at the package level. After that reading it looks like it's still a bad idea to go down that route because functions are far more testable when their only input is their arguments and the properties of their structs. But that means we need to fix up how errors work right now. I think that as a general pattern we should just define errors inline and in the event that we use errors as sentinel values we'll need to define it on the gui struct (ideally we want to minimise use of sentinel errors)

the articles I've been reading are
https://dave.cheney.net/2017/06/11/go-without-package-scoped-variables
https://dave.cheney.net/2014/12/24/inspecting-errors
https://dave.cheney.net/2016/04/07/constant-errors

I've just pushed some more changes. I'm thinking that now that we can't define our error messages on the package-scope, maybe we should consider using a i18n bundle for storing defaults rather than stating the default in the localize function, otherwise we'll be duplicating a lot of text.

edit: if I get the time I'll switch to checking on error type like in here https://github.com/golang/go/wiki/Errors rather than storing these on the Gui

@ghost
Copy link

ghost commented Aug 14, 2018

Not to hijack the thread, but there is something else to take into consideration. Both #95 and #89 are due to indexing on bytes instead of runes in https://github.com/jesseduffield/lazygit/blob/master/pkg/git/branch_list_builder.go#L144. This can be remedied quite easily, but then you must also provide a localization for abbreviatedTimeUnit.

@mjarkk
Copy link
Contributor Author

mjarkk commented Aug 15, 2018

The pkg/gui folder is now fully translated.
I'll later add an English translation file that can be used as template for other translations

@ponsfrilus
Copy link
Contributor

The English translation file as a template is a great idea! Thanks for doing that!

@mjarkk
Copy link
Contributor Author

mjarkk commented Aug 15, 2018

Jup that's what i thought to :)
It might be a bit annoying to add every ID and sentence 2 times but that would make it much easier to updates translation files and have a template to start with when making a translation for a new language

@mjarkk mjarkk mentioned this pull request Aug 15, 2018
@dawidd6
Copy link
Collaborator

dawidd6 commented Aug 15, 2018

Is it possible to use some kind of translation management system like https://weblate.org with this translation implemetation?

@mjarkk
Copy link
Contributor Author

mjarkk commented Aug 15, 2018

I'm not sure i need to look into that.

I have switched from Toml files for translation to just Go files because they are included in the build binaries because of that it (probably) isn't possible to use a translation service

It might be possible to do some magic with a file converter to convert all the .toml files to .go files but that would create 2 copies of everything

@mjarkk
Copy link
Contributor Author

mjarkk commented Aug 15, 2018

I have maybe found a solution to include Toml files inside the build binaries
It is possible using a tool from gobuffalo: https://github.com/gobuffalo/packr
But when using this you can't use go install anymore it needs to be: packr insatll
This tool might also increase the install output file with a big around like (1mb) that's around 30% more data

@dawidd6
Copy link
Collaborator

dawidd6 commented Aug 15, 2018

I would go for first solution: .go files. But we need to think about maintainability.

Translators would need to be notified somehow about new entries available to translate (maybe permament github issue?).

@jesseduffield
Copy link
Owner

jesseduffield commented Aug 15, 2018

Fantastic work man. I agree with using an english translation file, but I think we should take it one step further and not have defaults against the inline-translations. This means if we ever use the same message in different places (as is the case with some error messages) we don't need to duplicate the default string in two places: we can just say gui.Tr.SLocalize(key) and we'll ensure the key is in the english (default) translation file. Then when at startup we initialize the localizer we'll merge the default into whatever specific localization file we're using. What are people's thoughts on this approach?

@mjarkk
Copy link
Contributor Author

mjarkk commented Aug 16, 2018

Removed all inline translations from gui.Tr.SLocalize and gui.Tr.TemplateLocalize

gui.createPromptPanel(g, v, "New Branch Name (Branch is off of "+branch.Name+")", func(g *gocui.Gui, v *gocui.View) error {
message := gui.Tr.TemplateLocalize(
"NewBranchNameBranchOff",
map[string]interface{}{
Copy link
Owner

@jesseduffield jesseduffield Aug 16, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does this need to be map[string]interface{}? Are we able to say map[string]string?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Acording to go-i18n yes: https://github.com/nicksnyder/go-i18n#package-i18n-
But i haven't tested something else

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can create a custom type to use:

type Template map[string]interface{}

}
sub, err := gui.GitCommand.AddPatch(file.Name)
if err != nil {
return err
}
gui.SubProcess = sub
return ErrSubProcess
return nil
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we make this return gui.Errors.ErrSubProcess

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll test that out and see if the go checker doesn't spam me with errors

@@ -222,15 +223,15 @@ func (gui *Gui) PrepareSubProcess(g *gocui.Gui, commands ...string) error {
}
gui.SubProcess = sub
g.Update(func(g *gocui.Gui) error {
return ErrSubProcess
return nil
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same thing here

@@ -241,7 +242,7 @@ func (gui *Gui) genericFileOpen(g *gocui.Gui, v *gocui.View, open func(string) (
}
if sub != nil {
gui.SubProcess = sub
return ErrSubProcess
return nil
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and here

Copy link
Owner

@jesseduffield jesseduffield left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I left a couple comments. After those are addressed, I'm happy to merge :)

@mjarkk
Copy link
Contributor Author

mjarkk commented Aug 16, 2018

I hope this fixes this things you asked for :)

pkg/gui/gui.go Outdated
@@ -49,6 +49,9 @@ func (gui *Gui) GenerateSentinelErrors() {
}
}

// Teml is short for template used to make the required map[string]interface{} shorter when using gui.Tr.SLocalize and gui.Tr.TemplateLocalize
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we put this in the i18n package and then call it as i18n.Temp, just incase we need to call it from another package as well

Copy link
Owner

@jesseduffield jesseduffield left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just one thing :)

}
}

// Teml is short for template used to make the required map[string]interface{} shorter when using gui.Tr.SLocalize and gui.Tr.TemplateLocalize
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we move this to the i18n package and then call it like i18n.Teml so that we can can access it from any package, not just gui?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed it

@jesseduffield jesseduffield merged commit 090537a into jesseduffield:master Aug 16, 2018
@jesseduffield
Copy link
Owner

@mjarkk thanks again for all the effort you put into this PR it is fantastic work

@mjarkk
Copy link
Contributor Author

mjarkk commented Aug 16, 2018

NP i really like you're project :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants