solved How to translate the Dashboard?

Hello,

I would like to translate the Dashboard but I can not locate it as a module in the admin.

How to translate it? Where is its language tab?

Thanks
updated by @pch: 09/24/16 12:13:21PM

There is lots of stuff in the admin dashboard that is only in english. We here at jamroom.net only speak english, so can only offer admin support to english speaking admins.

Hi Michael,

Thanks for your reply.

Yes but you should have thought about it using language strings as you did in so many places within JR, even in some part of the admin.

I would like to translate basic words like: dashboard, users online, Data broswer, memory used, disk usage etc.

What is the easiest way to do it? There should be a way.

Thanks

nope, not right now, no way. Stuff that is pointed toward the admin user contains a lot of strings that come up from functions inside the core. Stuff that is not end user focused.

Example from the jrCore_init() function

That is a warning to the admin that gets displayed on the screen when they are trying to install jamroom telling the admin that jamroom requires the function 'mb_internal_encoding' to be turned on on the server.

Its not translatable. To translate it you would need to change the core files. There is no over-ride method for it.

To add to this, the dashboard and other ACP areas are only seen by admins, I personally don't think this area should be multi-lingual since there is usually only one person that ever sees it.


--

Douglas Hackney
Jamroom Team - Designer/Developer/Support
FAQ-Docs-Help Videos

Thank you both for your replies.

Yeah, I have 6 profile admins and none of them even speaks english. But they have access to the dashboard. The information in the Dashboard is very relevant to the admin team.

What should I do?

Thanks

Maybe provide them with some screenshots so they know what section is which? Unfortunately I don't have anything else to recommend.


--
Brian Johnson
Founder and Lead Developer - Jamroom
https://www.jamroom.net

Hope a solution will be found one day. Anyway thanks.

Yep - as more dashboard functionality is extended to admin users (not necessarily master users) it's something we will look into and get in place.


--
Brian Johnson
Founder and Lead Developer - Jamroom
https://www.jamroom.net

Thanks Brian.

Saying that the ACP is only seen by admins, isn't a valid reason. If you want JR to be used internationally, the ACP will have to be multi-language capable.

I speak English, so this isn't an issue for me. But your marketing seems to be focused more on the general population vs. the power user / coder / developer - which in that case, should offer a multiple language option in the ACP. If your marketing was focused more toward power users / coders / developers, I'd say English only would be fine, because most of them have to know English to code / deal with other developers.

Personally, I'd like to be able to adjust what is outputted when there is an error - and not have to edit the core files. Nothing looks more foolish that an error popping up on a high traffic / trusted website. Makes the admin look like he doesn't know what he's doing - even if the error wasn't the result of the admin's incompetence. If there's an error, that error should be in the logs and a generic error should be displayed like "the site is offline, we'll be back soon" not "can't connect to the database, etc. I hate giving an attacker any information. I'd rather let him think that the site is in maintenance vs. an error.

Is there a specific error you are thinking of? Note that JR can tell if an admin is logged in, and often will show a different (more detailed) error to an admin/master user than a regular user or user that is not logged in.

Thanks for the feedback.


--
Brian Johnson
Founder and Lead Developer - Jamroom
https://www.jamroom.net

No, no specific error to mention. I just want any error that the public sees to be adjustable to what I want it to say, which I assume, would be included if the ACP was mutli-language (those errors would have to be multi-language thus, I could set what I wanted).

Most of the time I'm logged in as the Admin. Maybe the errors are different for the public view. Honestly, I don't see a lot of errors with JR - to your credit - JR works great. But I don't want a generic error popping up on one of my sites, to the public, at 2am when I'm sleeping and is up until 8am when I wake up. I want the end-user to think the site isn't working because I took the site down, not because there was an error on the site. Being able to adjust what the error said via a language file would allow me to do that.

What we would need to do is:

1) assign an error "ID" to each error - that way we know WHERE the error was triggered even if the site admin completely changes the output of the error
2) The error text could then be translated by the site admin

This would be a BIG job (based on the number of possible errors points across all modules), so it's not something I can say will happen soon (i.e. JR 5.x) but I can put it down as a feature update for a future major release of JR.

Thanks!


--
Brian Johnson
Founder and Lead Developer - Jamroom
https://www.jamroom.net

Sounds like a plan.

Would it be easier to have the option to just to kick out 1 generic error for all errors in the public view. Honestly, that's all I would need. Have it display a site maintenance page. I think most people would opt for a site maintenance page over translation of every error. A site maintenance page / string is what I'm going to use for every error anyway. IPB has a html file they include in the root that just displays that the site is offline where there is an error type that prevents the site from being displayed... that method works for me.

That's not a bad idea - we'd just need to make sure the error is logged somewhere so we can assist if needed.


--
Brian Johnson
Founder and Lead Developer - Jamroom
https://www.jamroom.net

I thought all errors were logged? Anyway, just having that simple page would work perfect for me.

In regards to the ACP multi-language - might want to bump that up because the Chinese, Russian, and Indian markets are huge. For what you offer for the price, you'd be a hit in those regions - especially with Proxima. Which is something that should be promoted more because it's a mobile app centric world.

Since core is open source, people in those regions could totally start using JR as their core for simple sites which just need a login system, etc. Look at the top script sales in the PHP script category on Codecanyon.net

1. AJAX Contact Form 6888 sales @ $4
2. AJAX Contact Form 6293 sales @ $6
3. Contact Form Generator 5469 sales @ $14
4. Booking System
5. PHP Login & User Management 4259 sales @ $27

Focusing on those features could be key to getting people into JR.

http://codecanyon.net/search?utf8=%E2%9C%93&term=&referrer=search&view=list&sort=sales&date=&category=php-scripts&price_min=&price_max=&sales=&rating_min=

Just to be sure - I'm only talking about the dashboard - not the ACP. The ACP has literally thousands of language strings, so there's no plans to change that. It would also create a support headache on this end.
Yep - there's a couple of things we need to get into Proxima and the plan is to begin advertising/promoting it, as it has a very clear target audience and value proposition.

Thanks!


--
Brian Johnson
Founder and Lead Developer - Jamroom
https://www.jamroom.net

Yea, I guess that would create a support mess! I was thinking the ACP, but I guess you could work on that down the road when you had so many users that people from non-English speaking countries started to complain.

Proxima is so huge. That's one on the golden gems IMO. You were smart to make that part of JR's ecosystem and once developers learn about it, you're going to be very popular.