Efficient way to change from 'categories & topics' to 'forums & threads' in app?


#1

I prefer the terms forum/thread opposed to category/topic. I tried doing about 10 directory wide replacements from the command line but ran into rake errors afterward because the Thread class was already in use/was overwritten.

My next plan of attack was to change ‘thread’ terms into ‘thread_topic’, ‘thread-topic’, ‘threadTopic’, ‘ThreadTopic’, etc on the backend and change server texts and outputs to simply ‘thread’ et al.

But as you can tell that requires going through a lot of files 1 by 1 and making manual edits. Is there a better way?


Human Readable interface language selection
(Régis Hanol) #2

You’re in for a lot of pain :grimacing:

An easier solution would be to create a new locale based on the english version and do your changes there.


#3

@zogstrip yes it appears to be a painful path to take but between my existing forum’s vernacular/nomenclature and personal coding clarity in the future I consider this an important step to take. The .rb files and .yml files weren’t THAT bad. Plus, it forced me to get acquainted with the forum framework. For the record I think the jsapp and its naming styles will get tangled the most for me.

I’d be willing to bet that many current forums out there feel the same about the forum/thread vs. category/topic issue. Category / topic doesn’t sound right even though it is.

Thank you guys again for the wonderful framework.


(Jeff Atwood) #4

Well, good luck – you have opted in to a world of pain and suffering. (With the manual rename, I mean ;))


(Robin Ward) #5

There should be nothing to rename in the .rb files – 100% of the text should come from client.en.yml and server.en.yml


#6

I should specify changes made by me are not all manual. And @eviltrout, I’m attempting to change terminology throughout the entire backend of the framework. if grep is any indicator there’s about 25000 lines that need to be changed and with a careful replacement strategy for the various occurences I can narrow that down significantly.

If either of the authors would like to shed some insight or provide useful tips on how to accomplish this the least painful way please do.


(Kane York) #7

And why exactly do you think that is necessary :confused:

The translation files include every piece of text rendered.


(Simon Cossar) #8

You could try creating a plugin for customizing the UI strings:

  • create a plugin folder, for example ui-customization/

  • create a plugin.rb file with the content:

    name: ui-customization

  • at the base of the plugin, create the directory structure config/locales/

  • copy discourse/config/locales/client.en.yml and discourse/config/server.en.yml into your plugin config/locales directory

  • edit the values of the keys in those files to what you want them to be

  • upload the plugin to your server Install a Plugin


Invitation for new participants?
(Neil Lalonde) #9

I’ll just reiterate the words “pain” and “suffering”. You will never be able to update your repo to get bug fixes once you go this way.


#10

@riking - you are right about the text the user sees but what about the urls ‘c/’, ‘category/’, etc? What if from the beginning I don’t want to call a thread a category and a category a thread? How about calling a thread a thread. Obviously @neil brings the main setback to light citing the updating of bug fixes and so forth.

This is all very true. I thoroughly enjoy the discourse app and salute its team and original creators. if I didn’t I wouldn’t be here. But from my corner of the world I believe that categories should be named forums and topics should be named threads. I wish there was an easier way to do this.

Where is the original Thread class coming from? I reckon either thread safe or distributed cache files.


(Kane York) #11

That’s from Ruby, it’s about multithreaded programming. The Thread class is actually used by Discourse.

Can I try again to convince you that this is a bad idea?


#12

@riking you don’t have to convince me it’s a bad idea. I know exactly what it means and I dont necessarily disagree. However I also know what I need to do to accomplish my business goals. My existing forum isn’t HBO in numbers but it’s not insignificant either. I need users to be familiar with the terms. I myself don’t want to be querying a database and be jumping around between the terms. I also want a nice clean start.

Category and its variations is a pretty straight forward replacement. However I’m seeing about 400 occurences of XtopicX and XTopicX where X is any character. The occurence I am most confused about is the update to “‘topic’” in the jsapp. It could be translated to ‘thread_topic’ or ‘threadTopic’. That’s the painful part.


(Mittineague) #13

Nothing personal, I have no idea what your skill level is.

Discourse is open-source, so you can indeed do as you wish.
But IMHO if you think changing text strings in yml files is too much (granted, it could be tedious) then I fear working with all kinds of Ruby and Ember files is likely going to be even more of a challenge for you.

You have heard from the devs that work with these files daily and have been doing so for a long time. They have given you their opinion. If you choose to do otherwise, that is your choice. All the best, may you prove them wrong.


#14

@Mittineague seasoned developer. Been very much into python and ruby since 2008-09. I’ve worked PHP, Python, IBM and .NET jobs in the past. PHP sucks, .NET doesn’t make any sense and IBM can be evil in places.

The only part of the Discourse stack I’m not familiar with entirely is Ember. Let’s talk a little JS. First the DOM was just a mess. Then came prototype. Then came jquery and all the cool kids were using jquery from 2008ish (v1.2) onward. Forget stuff such as mootools and dojo for the time being. A lot of things were jquery until things like knockout and backbone started to appeal to people. Then suddenly there was buzz about Angular and React. Ember was mentioned but not much. I saw someone give a talk on it last year and was like hmm, interesting. But then as of just last month I have been forced to take another look because people at railsconf seemed pretty enamored by Ember. And here I am in front of it by coincidence.

It’d be nice if the JS people and online titans such as Google and facebook would halt pushing out open source projects for a while. I don’t want to have to relearn JS through a new framework every year.


(Régis Hanol) #15

Let’s say you manage to change all the references in the code and your Discourse instance works 100% fine. Then what? You launch it, your users start using it and will most likely enjoy it. All is good. A couple of months later, a bug is found and your users start getting annoyed. We push a fix in the master branch, but how will you apply it to your instance? Let’s say you manually copy & paste some code and the bug is fixed.
Then, our next release contains a feature that your users love and they beg you to update your Discourse instance. You’re in for the same tedious work you’re going through right now. Is that something you really want?

Also, please believe me when I say: your users absolutely do not care about what a forum or a thread is called in the source code.


(Marcin Rataj) #16

@will_io I agree with previous posters.
To minimize the pain you probably want to change labels in english locale and that is all.
It is totally safe and future-proof.
Do not touch source code, it is not worth the pain in support/maintenance.

You can use discourse-locale-override as a plugin boilerplate (read FAQ first).
In short you want to create plugin that adds english locale files (client.en.yml, server.en.yml) in which you override labels containing category and topic.


(Robin Ward) #17

I am hesitant to call a potential user of Discourse a troll, but… you can’t be serious can you?

There is absolutely no upside to converting the terms in our codebase which your users will never see, and only major downsides like you will never be able to upgrade to receive security and bug fixes.

This is a phenomenally bad idea. You should not do this.


(Yamikuronue) #18

It sounds like the reason for trying to edit the source code is the URL side, right? Since the on-page text is already customizable.

Is there a way to customize the software’s URLs today? Is that the real feature request here?


(loopback0 - TDWTF) #19

The guys who wrote the application are saying “don’t do this” and you should listen - this is a terrible TERRIBLE idea.

If you get the localisation, users won’t even notice that the back end calls it something different.
What if you spend days making it work (unlikely but whatever) just for the next update to come along and undo it all?


(Robin Ward) #20

This definitely does sound less crazy. Having said that, our app is not built to have all the URLs built dynamically so it would be a fair amount of work to support it. I think if we had a really good reason to do it we could start looking into what is necessary.