Why not merge this repo with i18next-parser?

[Elindorath]

🚀 Feature Proposal

This is more an open question and a potential opening of a discussion about the strategy to adopt than a feature proposal, but I think it would be smart to merge the different scanner/parser out there. What are your thoughts about it?

Motivation

Being the author of the new JSON v4 format, I made this PR to the i18next-parser repo to support it. Now I discover this other repo that I don't use.

From an outside look, those two projects seem to have the same goal even if I understand they don't have the same functional coverage (from there). I don't know which one should be incorporated in the other (they seem to have a pretty similar download rate according to npmtrends.com) but merging them would limit the work necessary to develop i18next, and would clarify what we should use when we want to integrate i18next into our projects.

I also understand from #213 that there are also concerns regarding the maintenance of this project. Merging would limit the risk of an abandoned repo.

@cheton, @jamuhl, any thoughts on this?

[jamuhl]

While personally, I would prefer having one option covering all - I would not be able to say which one to merge into the other...

[karellm]

I'm all for merging these projects and joining forces as stated in #19. I believe the maintenance would be easier and the community would benefit from a better project. I'd like to first hear the thoughts of the maintainers of the i18next-scanner and I'm open to do code reviews and feature reviews to see what is the best approach.

[goamn]

+1 for this, I am just starting out with i18next/locize and more options means more research between the scanner and the parser, kind of a waste of time. Please merge them together and get rid of one

[jamuhl]

My current feeling is - this module was abandoned. Looks like no activity for almost a year - no comments on issues raising the question if this is still maintained...

So personally I would give the contributors of this module some more time 1-2 weeks and then start adding a DEPRECATED message to the readme pointing to i18next-parser???!??!

[goamn]

I have finished researching i18next.parser and i18next-scanner. I don't see the benefit of either package? They don't seem to handle dynamic keys (i.e. t(enumString[enumIndex]). It seems as though the inbuilt "saveMissing" is sufficient. Obviously developers have to test their code so the UI will be rendered and the missing key will be uploaded.

Note for other newbies: I have decided to use the package i18next-http-backend which will load files from our server via fetch. For uploading missing keys, via the attribute addPath, I will create a backend point to call the save missing key Locize API endpoint. It would have been nice to have this option already available without an extra backend jump but obviously I can't mix two backends together (it's included inside i18next-locize-backend which is loading translation files directly from locize).

[jamuhl]

We recommend using the locize-backend during development - and if preferred the http-backend for production (if hosting translations yourself)...

saveMissing using http-backend to locize should be possible using the API endpoint https://docs.locize.com/integration/api#missing-translations directly as addPath: https://github.com/locize/i18next-locize-backend/blob/master/lib/index.js#L9 (hardcoding version to latest should be sufficient)

Not loading from locize during development might have a negative impact as missings will exist until you update your own hosted files

[karellm]

@jamuhl What's your take on @goamn's comment? I'm not currently using i18next and when I first published the parser, there wasn't anything built-in to manage catalogs.

[jamuhl]

Honestly, I was always surprised that people asked for a parser as in my opinion the "saveMissing" API was always easier to use (at least in the past when we not just used react-script and the built-in server. It was easy to just add some server endpoint for saving those new keys).

Meanwhile, I also see people love options - that's why both the i18next-scanner and i18next-parser were widely used / still be used.

In my opinion there is still the need for such an extraction tool - but would also understand you like to step back from maintaining the i18next-parser (as it is always difficult to maintain something you don't use - at least for me that is somewhat the case)

[goamn]

We recommend using the locize-backend during development - and if preferred the http-backend for production (if hosting translations yourself)...

saveMissing using http-backend to locize should be possible using the API endpoint https://docs.locize.com/integration/api#missing-translations directly as addPath: https://github.com/locize/i18next-locize-backend/blob/master/lib/index.js#L9 (hardcoding version to latest should be sufficient)

Not loading from locize during development might have a negative impact as missings will exist until you update your own hosted files

I've already tried this yesterday (and this morning), I get a 401 Unauthorized. It looks like it's not adding the header [Authorization: apiKey]. I've added the apiKey inside the main .init({ }) function as well as the backendHttpOptions passed into backend. Am I missing something?

[adrai]

We recommend using the locize-backend during development - and if preferred the http-backend for production (if hosting translations yourself)...
saveMissing using http-backend to locize should be possible using the API endpoint https://docs.locize.com/integration/api#missing-translations directly as addPath: https://github.com/locize/i18next-locize-backend/blob/master/lib/index.js#L9 (hardcoding version to latest should be sufficient)
Not loading from locize during development might have a negative impact as missings will exist until you update your own hosted files

I've already tried this yesterday (and this morning), I get a 401 Unauthorized. It looks like it's not adding the header [Authorization: apiKey]. I've added the apiKey inside the main .init({ }) function as well as the backendHttpOptions passed into backend. Am I missing something?

Please write an email at [email protected] and send your code snippets and possibly also the i18next debug output....
You may also compare it with this: https://dev.to/adrai/how-to-properly-internationalize-a-react-application-using-i18next-3hdb#save-missing

And if you're using i18next-http-backend, have a look at the customHeaders option:

loadPath: 'https://your-serever-url/{{lng}}/{{ns}}',
addPath: 'https://api.locize.app/missing/{{projectId}}/{{version}}/{{lng}}/{{ns}}',
customHeaders: {
    authorization: 'Bearer <LOCIZE_API_KEY>'
}

alternatively you can also use i18next-locize-backend and define your custom loadPath:

loadPath: 'https://your-serever-url/{{lng}}/{{ns}}',
projectId: 'my-project-id',
version: 'latest',
apiKey: '<LOCIZE_API_KEY>'

[goamn]

....

Please write an email at [email protected] and send your code snippets and possibly also the i18next debug output.... You may also compare it with this: https://dev.to/adrai/how-to-properly-internationalize-a-react-application-using-i18next-3hdb#save-missing

And if you're using i18next-http-backend, have a look at the customHeaders option:

loadPath: 'https://your-serever-url/{{lng}}/{{ns}}',
addPath: 'https://api.locize.app/missing/{{projectId}}/{{version}}/{{lng}}/{{ns}}',
customHeaders: {
    authorization: 'Bearer <LOCIZE_API_KEY>'
}

alternatively you can also use i18next-locize-backend and define your custom loadPath:

loadPath: 'https://your-serever-url/{{lng}}/{{ns}}',
projectId: 'my-project-id',
version: 'latest',
apiKey: '<LOCIZE_API_KEY>'

Right thanks, yes I was missing that customHeaders (it was in the i18next-http-backend readme.md). It works now :).
Before that I tried requestOptions: headers: {} which didn't work, I guess that's more for the headers of the OPTIONS request that it might send out.

[Elindorath]

Honestly, I was always surprised that people asked for a parser as in my opinion the "saveMissing" API was always easier to use (at least in the past when we not just used react-script and the built-in server. It was easy to just add some server endpoint for saving those new keys).

Just to add to the debate, the "saveMissing" API only works when using a backend. And even then, it doesn't pair well with a strict change tracking policy that requires catalog changes to be versioned with the application code. We could only use it during the development phase but it would require mounting an additional server in addition to the tools already heavy enough for a react-native app. The parser is a much simpler solution in our case.

[cheton]

Hi @jamuhl and @karellm

Although the i18next-scanner package was not actively maintained, it was widely used within our corporation (over 50 projects) and in worldwide for years, so far there're over 50,000 downloads per week on NPM registry.

However, due to family reasons, I may not have enough time to respond to issues and review PRs quickly. It's also fine with me to deprecate this repo on the README and seek @karellm's help to move major functionality from i18next-scanner to i18next-parser.

For the short term, I would like to seek a new active maintainer for this repo to address existing issues. If you've got a new maintainer, I can also transfer the NPM publish permission to him. Thank you!

[goamn]

I take my comments back regarding the i18next-parser. It is very useful on the initial localization of an application as you don't need to try to trigger ever warning, error, dialog, combination of logic to render the static content that i18next is wrapping. The parser will just parse and extract all keys.

As I am new to the localization scene, I'm sure I there will be other uses too. I ended up using the parser as there was a quick guide to getting it running: https://medium.com/swlh/internationalization-with-react-i18next-360a452e8809

[blindfish3]

I'm currently investigating i18n solutions for a new project and from my perspective a parsing solution is a must. It really reduces friction in the development process: developers can just mark the point where the translation needs to occur: they don't have to also go to other files and define keys and translations as I have seen in some solutions. I'm also concerned that this might lead to merge issues on larger projects where multiple devs are editing the translation files.

I would definitely favour an option where the source content can act as a key: I worked on Angular projects (parsing is supported) where we didn't add translations in the first release; but just had them marked for future-proofing. Using the source as key meant very little additional work was required.

Ideally a parser should include the option to automatically include context such as the file from which the content has come. In frameworks like Sveltekit where routes are based on files that makes it really easy to point the translator to the page where the translated content will appear.

So IMO there's definitely an argument to support this functionality; and having two options is confusing. A unified and maintained solution would be very welcome!

Just my £0.02. I'm aware that my perspective is perhaps a little naive; since I'm just interested in consuming these libraries and may not appreciate what is realistically possible 😅

[fersilva16]

I think we should deprecate one of them and have a migration plan. Keeping two options is confusing, and both are from the same org.

From what I tried, i18next-parser seems to do everything that i18next-scanner does but is maintained and with better API, options, and support for newer versions of i18next.

[capaj]

https://github.com/lingui/js-lingui has everything you need in one package and as a user I have to say it's much easier to consume and use correctly