GEDKeeper
GEDKeeper copied to clipboard
Serg-Norseman
Update manuals: common questions
- [x] Set the language in the HTML tag of files of Russian and English manuals
- [x] Full proofreading of the English manual by a native speaker (Kevin Sandal)
- [ ] Sync img.alt
- [ ] English manual: "archive" -> "repository"
- [ ] Article with links to external resources - convert to a table with country indication
- [ ] Write a new more complete version of the article Options
- [ ] Synchronize articles on laws in both languages
- [ ] Create a table with native replacements of names and locations in manuals in different languages, separately by articles
This task will be continued in the next versions. The help is still very weak.
I found some issues in the English help files. Want me to submit changes to my fork? Or is it already in the works?
This issue is circulating from version to version. As a memo.
You can correct what you think is possible - in your fork. Then make me a pull request. Then we will work together those points that will be controversial from my point of view. Then it will flow into the main development branch and if the corrections are promising - I will also make synchronous changes in my Russian help. Your authorship and input will also be noted in the general history.
I am a Git noob, so for any pointers you may have I would appreciate access.
Are you committed to using, for example, [ Left ] (use of spaces) in lieu of [Left] (no spaces)? I have seldom seen the spaced method used.
I do not see a particularly fundamental difference, but the method with spaces, I think, is more readable.
I did a pull request, forked the files, modified the help files, and now I am ready to push. The problem is I do not see a push in Visual Studio 2019. I have been reading up on Git, but there is a lot I still do not understand. FYI: Most changes are minor--there is still plenty of work to do. BTW: Love how you described Lua.
I have never used git functions from VS. I always prefer more control from the outside. However, here are two links: https://www.youtube.com/watch?v=jUiuIAZt6Dw (from 7:40) and https://docs.microsoft.com/en-us/azure/devops/repos/git/pushing?view=azure-devops&tabs=visual-studio
Note that you will be pushing to your local repository. But sending changes to the main branch of my repository is done via the site using pull request. It is best for you to search for an English manual in YouTube.
Status update: I am half-way through the English help files. I should be finished by Monday.
Thank you for the pointers on the use of Visual Studio.
You miss one important point: when starting work on a collective project, in the opensource, it is important to establish a common understanding and direction. Therefore, in the beginning, it is better to work with very small iterations and study at the same time. It would be much better if you made a small portion, committed it and made a pull request. We would discuss this, eliminate any flaws or misunderstandings. You do not do any push even in your fork.
But this is not so bad. You also do not update your fork. This needs to be learned. Before you make a pull request from your repository to mine, you must first accept from my repository new items created during your work. Of course, while you are working only on a help - the possibility of collisions is very low. But in general, these are very important steps.
You need to first learn how to work in small portions, and then do more ambitious stages.
Now, we have a situation where it is very likely that you will do a great job. And surely something will be such that we have not discussed and I can not accept it. And then we will begin a long and dreary process of agreeing on literally every little thing. Because the program's help must be synchronous in the two languages in which it is written. And there are many things that I could potentially disagree with.
I often work with big commits. Sometimes - just huge, with changes in dozens or hundreds of files. But I have been working on a project for 10 years and I know it thoroughly. Moreover, I completely control the process at all stages.
But the correct approach, which is generally accepted everywhere - to work as small as possible, atomic groups of changes of such size that the one who will be the approver - can quickly review each group of changes and make a decision.
I am about to make my pull request.
Sorry for the generic comment on each item. sigh I am slowly getting the hang of this.
In the file gkhAuthors.html there is a reference to WMR and WMZ for donations. Both seem to be for WebMoney--is this accurate?
I also have an idea to stop using the term "help" and switch to using the "guide" or "manual". I do not know which term is better
Generally speaking a guide is a collection of pointers and tips while a manual is more detailed and precise. I believe 'manual' is the better term here because some of the information is quite precise. Other information will become more complete as time goes on.
I have updated the Options article. It is not complete, but it does show a methodology that needs your acceptance or rejection. Note: several dlgOptions...gif files were added.
More updates to the Options article. Where "TODO" is located I need some direction on what to put there.
I created a document in dev_info called Options_article_dialogs.docx for documentation.
I cleaned up the 1, 2, 3, ... arrows on some graphics I made in GIMP 2. If you dislike that background on the current graphics please let me know and I will commit these updated ones.
I just updated my fork with the updated graphics. I think they look cleaner. Also, they were created with GIMP 2.