Not planned Separate front-end from back-end (admin / ACP) phrases

Sar

Active member
Hi,

I asked this several times on vB forums, and many folks want that too.

It's about language. We are non-english portal, and translating it, is a pain in the ***, as we can't know which are user based phrases, and which are admin phrases.

We want to have admin phrases in English due to transparency and easier translating new updates, so want to translate only user phrases. But now, we are forced to translate almost everything.

Please consider it.
 
Upvote 17
This suggestion has been closed. Votes are no longer accepted.
(I forgot to [like] this one)

See this posting and all the postings that follow in that thread for more discussion about the benefits for us to be able to translate the 'ACP/backend' seperately from the 'frontend'. This was and is really a big issue when you use vBulletin and are using a local translation instead of the default English language. For my platform it comes down to this: I definately would like to have all admin/mod functionality (regardless of being it in the ACP or the frontend) left in English and only, really only the end-user (registered users/guests) functionality translated into our local Dutch language.

Maybe this is technically an impossible task for products like vBulletin and XenForo, but it is sure something that would be very welcome.
 
So if i create a new addon, like lets say a gallery (vbgallery for instance has like 800 or more phrases, 0ver half of them being in acp), there is no way of not fetching the acp phrases and gallery phrases on front end forum pages?
Doesn't that give some overhead memorywise?.. specially on pages that dont need any of them (thinking of the descriptions of all the settings :eek: etc...)
vBulletin and XenForo work in very different ways.

vBulletin has to load an entire groups of phrases in order to access just one phrase from that group. This can lead to massive amounts of memory wastage due to unneeded phrases sitting idle in memory.

On the other hand, a primary goal we had when developing XenForo, (which we achieved due to the fact that XenForo was written from scratch with this goal in mind,) was to load only those phrases and templates that are actually required by the page being rendered. With a very few exceptions, where a small number of phrases are always loaded, XenForo meets this goal. You will notice that there are no phrase groups in XenForo - this is because the system does not require them, we can fetch exactly what we need and nothing more.

Therefore, there is little to no memory overhead at all.
 
I think that this feature in my OP is not that important for the moment and might be kept for later development.
There are other more important features to be focused on.
 
I think that this feature in my OP is not that important for the moment and might be kept for later development
Well... I think it's actually a really important and valuable suggestion you've made. How we all could benefit if all the admin/mod functionality (being it in the front- or backend) was to be left alone in the default English and all the enduser functionality in our local languages! vBulletin also doesn't split those areas when it comes to translations and it's such a mess :mad:. The Dutch company that produced a much sought after/needed professional translation of the vBulletin 3.x series also chose -rightfully so!- not to translate the ACP in Dutch, but still Dutch phrases are popping up there all over the place, because indeed like here...
... phrases are shared....

A solution would be very welcome.
 
Well... I think it's actually a really important and valuable suggestion you've made. How we all could benefit if all the admin/mod functionality (being it in the front- or backend) was to be left alone in the default English and all the enduser functionality in our local languages! vBulletin also doesn't split those areas when it comes to translations and it's such a mess :mad:. The Dutch company that produced a much sought after/needed professional translation of the vBulletin 3.x series also chose -rightfully so!- not to translate the ACP in Dutch, but still Dutch phrases are popping up there all over the place, because indeed like here...

A solution would be very welcome.
What about an add-on which sets the user language to english, if the user is in the backend and set it to dutch, if you are in the frontend?
 
I apologize for necroposting yet again, but I'd like to add my two yen to this discussion.

I'm planning on localizing XenForo for a Japanese website. Ultimately I'll probably want to complete the localization job so that non-English-speaking Japanese users can enjoy using XenForo. But I personally don't really need a Japanese admin interface. In fact, I'd rather admin my site in English. So for the time being, I'm guessing my best option would be to use an incomplete language pack, which I don't consider an ideal way of doing things.

While testing out WordPress I got in the habit of using the WP Native Dashboard plugin. This nice little addon allows each user to specify the language for the dashboard, so one can browse a blog in Japanese but admin it in English, or vice versa, etc. It's a great idea.

It's not perfect, though. WP Native Dashboard works well with a standard WP installation, but it isn't able to affect the behavior of other plugins. If I set my site to display in Japanese and my admin language to English, the control panel for my caching plugin still shows up in Japanese. So while I applaud the efforts of the plugin's author, I feel this is something that really needs to be built into WP itself to work right.

I think XenForo could benefit from the same sort of thinking. I'd like to see a setting that would allow each admin user to specify his or her preferred language for the admin UI. This would allow people like me to use my preferred language to admin without using an incomplete localization.

I don't know if such a setting would require any actual separation of resources, other than for the convenience of translators. And it may be that a plugin (like the one suggested by ajnos in the post above) is all that's needed. If a plugin will result in inconsistent behavior of the sort I experienced with WP Native Dashboard, however, I'd prefer that this functionality be built into XenForo.
 
I just were going to suggest the same: Separate Front-End language and ACP-Back-End language.

We use a localized version of a well-known forum in German, but want to use an English backend, since it doesn't make any sense to translate english technical terms to gibberish german rather un-technical and hard to understand terms.

Plus if you have a localized version of the ACP it is hard to find support on the internet as well as letting someone experienced/XenForo support into your localized ACP.

Any chance to get a separate FE-language and ACP-language realised?
 
honestly, it is much easier for me to use the english-language ACP than the german one.
Especially when you get feedback here in the forums, it is much easier to find what you are looking for then in your ACP.

Xenforo is actually fine as it is, no need to change anything on this as per my point of view.
 
You will notice that there are no phrase groups in XenForo - this is because the system does not require them, we can fetch exactly what we need and nothing more.
Yes, XenForo needs them if it wants to be attractive for non-english speaking people. Many phrases are shared between the frontend and the acp, which makes it impossible to make a proper english-only ACP and a german-only frontend. It would help immensely if you could at least avoid using ACP phrases in the frontend and frontend phrases in the ACP.
 
Yes, XenForo needs them if it wants to be attractive for non-english speaking people. Many phrases are shared between the frontend and the acp, which makes it impossible to make a proper english-only ACP and a german-only frontend. It would help immensely if you could at least avoid using ACP phrases in the frontend and frontend phrases in the ACP.
I agree with this since the french translations (among them a payed one !!) are pretty miserable in my opinion. And since the language option is database related in the user table, it is not that easy to switch.
 
This feature is long overdue the front-end and acp should not be on the same section. Also lines should not be reused in other sections in my language location of a line can make a difference how its translated., have no idea if this is the case.
 
At this point, I'm going to simply say that this won't happen. There are and always will be phrases that are reused in both places and we won't distinguish them. Beyond the phrases actively reused because they're very basic ("email", "password", etc), there are phrases reference by the code which won't differentiate. There are also other programmatic areas where they're used in both locations.

There is some discussion in this thread regarding choosing a different language for the ACP and that part has been implemented.
 
Top Bottom