Privatebin: Option to Edit English language

[planetahuevo]

I was trying to change some texts myself and adapt it to my personal use of the code (great by the way, thanks! )

So I though I could use the languages, to change some small things on the english without affecting the rest.

But I have not been able to make the english file en.json work on my install.

Steps to reproduce

1. Add en.json to the folder of languages
2. Force en language on config.

What happens

Nothing.

What should happen

Use my en.json language instead of the defaults

[elrido]

Hi, This is totally possible, but since the English language is the default, you need to edit the message IDs in the source code (and all translations, in case you still do wan't to use them - if you don't it will remain untranslated English as it won't find the message IDs in the translation file.)

Alternatively, if you are fine with running an English only instance, you can create a new non-existing language and set it as the default in the configuration:

• How to add a not yet existing language code (the example provides Klingon and Leetspeek)
• disable language selection and enforce your "new" language in the configuration

[planetahuevo]

Hi @elrido
Thank you for the fast reply.
What I am suggesting is that you make the default a default (when there is no translation, use this) and put English where it should be, as a language, so nobody needs to modify the core (losing translations on the way) just to change a word or a comma on any English text.
I hope you can consider this feature on further releases.

I will see what I can do, I do not want to modify the core at all.

Thanks

[planetahuevo]

Also related, I would like to suggest to move into the IETF language tag so regions can be added too.
en-GB
en-US

That will allow to keep en as default, but we could create a "en-US" or any other region with custom translations.

What do you think?

[elrido]

I was aware of both localization and internationalization when I implemented this feature and have chosen deliberately to only do the latter one, as we don't have the size of community (and I suspect we still don't) to support not just (among others) en, fr and de, but also en_US, en_GB, de_DE, de_CH, de_AT, fr_FR, fr_CH, etc.

If we do find willing maintainers for each of the offered languages and a fallback scheme for the ones not maintained, then I am happy to extend this, but until we get such merge requests of conflicting locales for existing languages, I would rather focus on adding entirely new languages instead.

If this request is about you wanting to implement, say, en_GB instead of our presumed en_US-ish language and have already created such a flavor, and are willing to maintain it over the next years, then please raise your merge request with en_GB.json file and I'll be more then happy to figure out a solution with fallbacks, etc.

[planetahuevo]

Ok, I am sorry if you have been offended by my comments.
You do not need to offer the translations if you do not want.
I tried creating my en_GB.json on my install and the system is not capturing the language, maybe this is a bug and it should work.
Can you please confirm that if I create a new language with "en_GB" an put that on config it will use that instead of "en" or any other?

EDIT:
I am not English by the way and I do not consider your translation US-ish or anything like that.

Thanks

[planetahuevo]

Also, my original request is to be able to use and edit en.json on the current installation without modifying the core files which is something is not possible at the moment.
I suppose you won´t consider to do this either.

[rugk]

BTW what is the underlying use case you try to solve? Why exactly did you want to change the translation in the first case?

[elrido]

Please have a look at the document re. how to add a not yet existing language code (the example provides Klingon and Leetspeek). I assume you will have to use a two letter one and en_GB won't work.

If you are willing to maintain this language version, please do create a PR adding just the JSON file and I do offer to look into adding the new logic to support this. But it won't work at the moment, as this isn't supported. We can make it work, though, in principle, as we already have to parse the full localization strings that the browser requests to figure out the language component.

I had just tried to explain the reasoning behind my design decision at the time (3 to 4 years ago) - sorry if this came across as harsh.

[planetahuevo]

I am trying to use my own words for things like: "Because ignorance is bliss" and other text all around the setup. I just want to customise it. This is not a "better" translation but a customization and make my install with wording that I think is better for my users.

For example, to change the note, you need to use a setting in config, which, imho, it is not needed if you provide a en.json file and let anyone to customise it however they want.
Another example, you have this issue here on how to change the word "paste".
https://github.com/PrivateBin/PrivateBin/issues/397
Well, I do not like "document" either, but the point is that I should be able to change any text around the app.
For any other text, there is no conf option so the only solution is to change the core so far, or ask you guys to do it raising an issue and discussing about it.
This is my proposal:

• Create a "default" language, so you liberate the language "en".
• then en.json will be available on the folder with the rest of languages.
• People can use en.json to create another language or just modify it to customise their own installation.

I think this is the best way to allow text replacement without any more config options and without changing how the code works.

Hope it is clearer now.
I would love to hear your thoughts.

Thanks

[elrido]

Ok, so for your use case of customizing just a few of the English bits, you can just change the message IDs in the source. This means that these strings won't be translated if someone with i.e. a French browser surfs to your instance, but instead they will see your custom English string. You can find the bits to replace quickly using your IDEs global search & replace function or the grep command on the CLI. They will be either in js/privatebin.js or somewhere in lib/ or tpl/, if they are used server side.

The introduction of an en.js which simply duplicates the strings so that they can be edited would of course also be possible, but only simplify this one special edge case, while slowing the load and execution of the application for any browser with English language preference or a language that we don't support (yet), as they also get the English default.

So I think we have given you multiple options on how to do this in the existing logic and a recommendation for the particular use case and I therefore resolve this request.

[planetahuevo]

I have failed to make you see that my request is not that 1 user case and not particular to me at all.
I tried to point you to several issues you have opened that would be closed forever in the future with this simple change.
You are forcing the users to modify the core code for simple changes on text, which is not something that I recommend, so people can be able to update to new versions in the future.

So I think we have given you multiple options on how to do this in the existing logic and a recommendation for the particular use case and I therefore resolve this request.

I know I have options, I knew about the options before I wrote the feature request, but I think this is a better way to do it an I was trying to help the project the way a non developer like me can, providing testing, different use cases and proposing solutions to those problems too.

Now you close it without waiting or hearing any other people opinions.
It is ok. Your project, your rules.
Thank you for your time and for the great code you offer here. I will try to see what can I do with it myself.
Have a nice day.

[qol3m]

I struggled with this myself yesterday, since the FAQ says "just edit the language files", but you apparently must edit the core file to make any changes in the English language, which essentially means you must edit the core file to make any language changes whatsoever (since it would be pointless to change all languages except English).

So I don't really think an en.json file would be an "edge case". It would allow us to not edit the source file, which would be useful in case bootstrap.php gets updated.

But since there is not that much to edit in the source file, I guess it's not a very urgently required change. Perhaps I would adjust the FAQ, though.

[planetahuevo]

Thank you for the support @qol3m
Maybe they can consider to open it again and add the "discuss me" tag into it.

[elrido]

I am happy to review any pull request for such a change, if someone were to make it. I don't think any further discussing is required, someone just needs to do the work. If someone please would step up, I am happy to work with you.

[planetahuevo]

Thanks.
I am afraid I am not a developer, trust me, you do not want me to try to code this at all...
But I will have a look and ask a friend of mine to see if he wants to collaborate on this.