Project status and feature request to use embed po files

[tbonnardel]

Hi !

I find your lib very attractive since it implements gettext in native Go and supports .po files, that are not the case for the other libs.

The wip extractor tool in CLI seems to be very useful although it's not include in v1.4.0.

I wonder if the project is still maintain. Indeed the last stable version was released on 2018 whereas some cool features (such as the cli) are in the pipes.

Furthermore, it would be great to accept a File instead of a raw path to point a .po file in Configure. It will offer the possibility to embed a po file with the new embed api (since Go 1.16).

I'm open to contribute and send PR if necessary.

[leonelquinteros]

Hi @tbonnardel !

The project is still maintained and got some good contributions during the last years. That said, progress has been slow as I found myself busier than before to work on new features.

I'm glad you found the CLI extractor useful for your use cases, that feature is one of the few that are ahead the last stable branch and I'm collecting feedback to be able to include in the next release (to be created), as I don't use the CLI tool myself.

I'll work on a new release tag for the lib so everybody can benefit from it without having to hack dependencies or work against the master branch or a commit hash.

Now, about your proposal on accepting a File at package level to Configure, I'm always open to contributions and these that come with PRs are the ones I like best xD That said, there are a few comments before moving forward:

Note that you can use the Po type to parse a single translation file, so if you have already an embed'ded file as a []byte, you can Parse them and use as follows: https://pkg.go.dev/github.com/leonelquinteros/gotext#Po.Parse So for a single translation file, you should be already covered. If you need to go further, you could then use https://pkg.go.dev/github.com/leonelquinteros/gotext#Locale.AddTranslator to add several Po objects so you can support several domains.

Then, the entire idea of configuring the library path (root level), language code and domain is that the package will "auto-load" (and cache) the corresponding translation file depending on the current language and domain for a given session. So, it's not about a single file, but about an entire filesystem structure with as many .po files as needed. All that "auto-discovery" work is simply based on naming conventions for these files, so I don't see now hot that can be (transparently) adapted to work with embedded files. I can think of a map[string]File or map[string][string][File] or something that may work, but I don't see advantages on implementing such thing is this package. It may be more an external "wrapper" for a given use case.

Does that makes sense?

Please tell me more about the use case you want to approach and we can figure out a solution that may (or may not) require a new PR.

[tbonnardel]

Thanks for your precise answer!

Indeed we can easily implement a wrapper to load embeded files with the design you describe. It works and integrates well into gotext. I can notify you when I finalize this wrapper if you want to integrate or not this wrapper (that can also be an external one as you said).

About the CLI extractor, I would like to use it in the following context:

1. Write my source code with gotext.Get in an unique language (english)
2. Extract strings to translate (thanks to the CLI tool) which generate .po files
3. Use an internationalization platform which centralizes all translation processes of my projects
4. Update .po files in consequence
5. Embed these .po files to the source code

That's why the CLI tool seems to be a major piece of this process. As soon as I finish the file embed wrapper I will take a look at the extractor and will give you my feedback (and why not make improvements if needed).

I will keep you updated asap!

[hi019]

Here's how I load translations from an embed:

func (s *Service) AddLocale(fs embed.FS, tag language.Tag) error {
	l := gotext.NewLocale("", tag.String())

	b, err := fs.ReadFile(fmt.Sprintf("assets/locales/%s/default.po", tag.String()))
	if err != nil {
		return err
	}

	po := gotext.NewPo()
	po.Parse(b)

	l.AddTranslator("default", po)

	s.locales[tag] = l // s.locales = map[language.Tag]*gotext.Locale

	return nil
}

[snowdream]

@leonelquinteros Thank You for your gotext.

As we know , we can use gotext to add po and mo from disk. But now ,When i use go embed to package the mo and po into the go binary. I want to use gotext to add po and mo from embed files.

Can we support the feature?

Maybe @hi019 'method works, But we need more. We need to use gotext from embed files, as the same as from the disk.

[didrocks]

I think thise could be easily done with what was mentioned before if you use your own Locale object. The only missing pieces I think is a way to override the global config storage object.

@leonelquinteros what do you think of a PR to allow settings globalConfig.storage object? Then, this is up to the loading wrapper to set Locale.Domains map to desired manually loaded Translators like embeeded or not po as []bytes or so. And then, the project can use gotext.Get() or any root level methods transparently.

I can see this being very useful if you want to test your code from your own repo (using embedeed po files if you detect the root of your projects), while still being able to build your project and deploy to an installation, which will load from /usr/share/…

[leonelquinteros]

@didrocks It makes totally sense to add getter/setter for globalConfig.storage actually. Go for it.

[didrocks]

@didrocks It makes totally sense to add getter/setter for globalConfig.storage actually. Go for it.

Thanks! Here we go, let me know if you want me to change anything :)