Terminology rewrite sprint


#21

Great thanks!

-G


#22

For those pages that currently doesn’t exists and that imply names that will be renamed and I want to create, should I write them as the old name and leave the rename sprint do the change or should I write the them with the new terminology and leave them unapproved? (I can’t leave one page unapproved for the first edition, so should I do write the page with the old convention? This case is special because it would need a redirect because the page name itself has the renamed string (duck))

Example: Select_All_Ducks or Select_All_Handles?

Cheers!
-G


#23

Once the sprint done and synfig with new terminology released, all the translated pages will be out of date ; how can we work on that ?

Addind an info banner on all translated pages until they will be rewrited?
Is it possible to automate some info banner (“Warning, this page contain old references” <— translated in adhoc language) for translated page who need to be rewrited ?
Ideas ?

see(:ya!


#24

I did a testing rewrite for two pages:

So, I think everything is ready to start the renaming. Any thoughts?

Let me think… We can add an info banner, but that will require to add a special tag code to EACH translated page…
There is another idea to integrate our wiki with transifex.net translation service. That way people wil translate the wiki pages the same way as they translating the interface elements. When some paragraph in original English version is updated, then translators will automatically get notified about the change and can re-translate changed part. All translations should be automatically displayed on the wiki so the end user should look through them in the same way as he reading ordinary wiki. That’s the idea. But its implementation requires some efforts. A full-time week + testing period…


#25
  • can we add some syntax and formatting recommandation to the terminology sprint ? (short key, command path, literal, when use bold/italic … )
  • can you add a line about screenshot for term print in the initial terminology rewrite sprint message ?
  • could be interesting to make a libre gfx community (libre graphic world, deviant art, inkscape users, …, others … , …) call about the doc sprint … what do you think ?

it’s the case … no ?
* Add the {{Category|NewTerminology}} at the top of the page. We need that because it is possible that while we doing that spring someone will add the new pages to the wiki. Surely the newly added page won’t be listed at wiki.synfig.org/wiki/Dev:Sprints … erminology and thus it won’t be updated.
or you have just added that line ?

could be awesome … but seems to be a lot of work… !

see(:ya!


#26

I think this change is wrong.

  • BLine -> Spline
  • BLine Point -> Spline Point
  • BLine Tool -> Spline Tool

Please don not make this change…

More accurate is

  • BLine -> Bezier Curve
  • BLine Point -> Bezier Point
  • Duck -> bezier control point
  • BLine Tool -> bezier curve Tool

#27

The discussion about this was taken in the synfig-devl mailing lists some time ago and now in closed.
See discussion chart here.
docs.google.com/spreadsheet/lv? … ERzMjBDQVE


#28

Another thing , has a few page are planned to be read, can we do something to [b]reference/b and [b]do something/b with the comments present in the doc ?
exemple of comment :
in Color Editor Dialog
[…] images cannot hold negative alpha or bigger than 100% (Are you sure?).

nota: since some page i edit, i format then in italic


#29

I wrote that page long time ago and I didn’t know (didn’t research enough) if there is any image format allow alpha outside 0-100 :blush: . If unsure please, remove and place it on the talk section. As I mentioned before, official wiki pages are alive and under continuous revision. :smiley:

-G


#30

Agree: all comments meant for ourselves as the doc authors and the experts (programmers, maybe also authors) should be placed either in this forum or the talk section. All errors should be placed in bugtracker or (if doc errors) in talk section as well.

Everyone, please check the talk sections when editing the docs. Thx.


#31

I think we should concentrate at one task at once. The terminology rewrite is a huge task itself, so I don’t warn to make things even more complex by mixing with other tasks.

You right, we have to deal with outdated screenshots somehow…
My proposal is to postpone this task for separate sprint.

Well, I don’t like the idea attracting random (not related to Synfig) people into such task, because editing the terminology still requires some understanding of the text meaning.

No, it’s not exactly that case…
But wait, I have some idea. I could write some code for mediawiki which will display warning for pages which doesn’t marked with {{Category|NewTerminology}}… This shouldn’t take much time…
I’ll do that after the sprint (after the release). Please ping me if I will forget that. :slight_smile:


#32

I think we should concentrate at one task at once. The terminology rewrite is a huge task itself, so I don’t warn to make things even more complex by mixing with other tasks.

You right, we have to deal with outdated screenshots somehow…
My proposal is to postpone this task for separate sprint.

Well, I don’t like the idea attracting random (not related to Synfig) people into such task, because editing the terminology still requires some understanding of the text meaning.
But the post on the main website is good idea.

No, it’s not exactly that case…
But wait, I have some idea. I could write some code for mediawiki which will display warning for pages which doesn’t marked with {{Category|NewTerminology}}… This shouldn’t take much time…
I’ll do that after the sprint (after the release). Please ping me if I will forget that. :slight_smile:


#33

The sprint is LAUNCHED! - synfig.org/cms/en/news/termi … te-sprint/

Please spread a word. Everyone are welcome to participate. :slight_smile:


#34

I have updated the packages with some minor fixes. All sprint participants please re-download and update - http://download.tuxfamily.org/synfig/packages/binaries/


#35

I’ve found that sometimes the verb Encapsule (wrong syntactically) is used instead of Encapsulate. Beware of that.
-G


#36

Thank you. That’s why we advice to use “encapsul” string match.


#37

Warning! Do not upload new versions of existing images. they are updated without revision!
Instead upload it with a different name. I’m adding the Synfig’s version at the end:
Image_name_0.63.06.png

-G


#38

4 hours to update the terminology of 40 pages. 2/3 of them only adding the new category but needed to checkout all the terms. Off for today.

There is a total of 175 pending pages to review. It would be about 20 hours or work.
Come on! :slight_smile:
-G


#39

working on it… :slight_smile:

Cheers OHo

Edit: just a few… too tired now.


#40

Found loads of additional renames to do at “Adding Layers”
All occurrencies of “inline canvas” should be renamed to “group layer” as well, right?
It has been used as a alternative name for “paste canvas” e.g. “{{l|Paste Canvas|Inline Canvas}}”

Z., please add this to the rules for search/replace at the top level post in this string, if this is true.
Thx.

Cheers
OHo