That is good to hear. Happy to help!
Wish you all the fun it needs!
Konrad
the red “Dev” bubble is a built in feature, or you develeoped it?
I have multiple clusters, and it could be a good thing to “comment” the same look servers
1 Like
When you start graylog from the sources as described above the dev bubble appears.
Please open a feature request and I will see what I can do for 3.1. It sounds something people with clusters need 
Hi Konrad,
I added the localisation packages to the package.json for node in the source and it builds.
I am able to hard code, foreign characters intoi the source and see them rendered within the graylog UI on our dev server.
Looking at the structure of graylog, it just imports all the pages. On option would be to use a language detector to determine the language and then change app routing accordingly.
In this scenario, there would be two copies of the source tree for the web interface at following urls as an example
http://127.0.0.1:9000 - default english version
http://127.0.0.1:9000/fr - say french version
This would mean that the compiled build would get huge very quickly.
An alternate method would be to hard code each language support within components of each page using the language detector to determine which to show.
The second is probably better in terms of size of compiled output / execution time.
What are your thoughts?
Jake
I’m not Konrad, but what you usually see with multi-language projects is:
- Each language pack offers a library or file with the localized versions of all application strings.
- Each time a string is used, the contents of said string are retrieve from the language pack in question.
Building duplicates of the full web interface for each language will make for explosive growth and will also make future development a big problem: making one update will touch N files, where N=NumberOfLanguages.
Apologies Totally_Not_A_Robot,
After looking at the choices for localisation, i liked either i18next or react-intl packages.
Some of the localisation options can use json files to provide localisation which is probably the way forward thinking about it.
Any further thoughts?
Cheers
Jake
1 Like
The localization packages should prevent a copy of the source tree.
What packages did you choose in the end? Then we could disuss how to approach the problem?
From my former projects we had a json/yaml file which contained the translations. In the source code of the gui you only find the keys of the json/yaml files.
I would also suggest to keep a state of the language since we use react. I am sure react has a package which fits the needs.
So I just saw your answer. I would go for https://github.com/i18next/react-i18next since it is more active and is widely used (as it seems).
1 Like
Hi Konrad,
That is the conclusion that I came to as well. I looked at other options.
I have that in the package.json with hard coded asian character strings in the source , just to check it would compile.
Ii is my understanding that you would have to import localisation into each react component that is used within the web interface i.e. adapting the source code for the component to display text for the given language which is detected via the browser using the language-browser npm plugin for react. Am I correct?
Cheers
Jake
1 Like
So far so good. Yes every component which you want to translate would need to import that.
My suggestion would be that you pick a small component (like TokenList.jsx) and translate it.
If you want to contribute your work to Graylog, you would want to create a pull request with a minimal working solution, so other developers can discuss it with you. Because adding new translations from there should be not a problem since English should be always the fallback. We are right now full with work for finishing 3.0 so feedback could take time.
1 Like
Hi Konrad,
Either being very daft here but I cant find TokenList.jsx in source tree anywhere.
I looked in the src for the graylog-web interface directory
Cheers
Jake
Hi Jake,
no I just was not specific enough. Sorry for that!
I assume you work on master branch. Than the TokenList.jsx should be here: graylog2-server/graylog2-web-interface/src/components/users/TokenList.jsx. I would recommend it, because:
- I have written it
- It has tests which you can use if you want
- It is really simple IMHO
I hope I could help.
Hi Konrad,
I wanted to try to build Graylog 2.5.1 using graylog-cli. Remember I already have a working 3.0. beta 2 version.
I can compile it properly via command line as shown below.
However, in Intellij it does not start, the error out put is at https://pastebin.com/7hx63hmf
Is it a depenadancy problem with guice?
The intellij configuration are identical betwenn 2.5.1 and 3.0.
I ran the following command to download the source
graylog-project -D bootstrap --manifest=“manifests/2.5.json” https://github.com/Graylog2/graylog-project.git
There were now error.
What did I do wrong or am i missing something?
Cheers
Jake
Hi Konrad,
I am running Mongo v3.6.9 and Elasticsearch 6
Cheers
Jake
Hi Jake,
this can work, but I never tried that. I have separate repositories with separate ElasticSearch instances and mongodb instances for every branch I need. You can always go up (since we must support upgrades) but going down is a different problem.
So I suspect that there lies the problem. If you want to work with 2.5.1 either clean up (like elastic search, mongodb and build (mvn clean in graylog-projects-internal) or start a new from a fresh repro.
This is not much of a help, I know. But I guess you are right with your assumption that the problem lies with guice.
Greetz,
Konrad
Hi Konrad,
I did the graylog-project command in a separate directory on the same ubuntu server say /home/ubuntu/graylog-2.5
Reused the same graylog.conf file in the graylog2-server directory
Ran mvn compile in the graylog-project folder within /home/ubuntu/graylog-2.5 and it worked.
Imported project and setup configuration as per graylog 3.0
I thought both 2.5 and 3.0 supported Elasticsearch 6 and Mongo 3.6 so I have the same for both builds.
I will try the mvn clean in graylog-internal in the 2.5 directory and see what happens.
Cheers
Jake
Hi Jake,
just to be sure I understood correctly that you did checkout a separate graylog-project-internal as well?
But a mvn clean should also help If not let me know and I take a deeper look.
Cheers,
Konrad
Hi Konrad
I used the following command to check out each branch
3.0 - master branch
graylog-project -D bootstrap https://github.com/Graylog2/graylog-project.git
2.5
graylog-project -D bootstrap --manifest=“manifests/2.5.json” https://github.com/Graylog2/graylog-project.git
The graylog version that compiles is version 2.5.2 ,but the lastest 2.5 release is 2.51. Could I have a further update branch tahn the 2,51 release causing the problem?
How do I check out the graylog-internal ? I followed the guide at https://github.com/Graylog2/graylog-project/blob/master/README.md
Does that not check put the hgraylog-internal?
Cheers
Jake
Hi Konrad,
It appears that the manifests are pointing to version 2.52 rather than 2.51. In the manifest file it just says 2.5.
Cheers
Jake
hi Magneton,
I have the same problem “Parent path /etc/graylog/server for Node ID file at /etc/graylog/server/node-id is not a directory”. Could you please write more about the solution? Since I’m new for developing this… Thank you!
Cheers
Beanzi