링크처리는  유저에게 옵션을 주는것또한 한 방법이라고 생각합니다.  default 는 그냥 현재창으로 되어있고 새창을 원할때 새창을 쓰게하는 체크박스를 제공하여  유저에게 선택권을 주는것도 한 방법이 아닐지 해서,,,,,

/*    -------------------------------------------------------------
    function setLinkAttributes()
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Description:    setLinkAttributes finds ALL anchor links and
                    can set new attributes. The following script
                    specifically finds anchor links labeled as
                    external, and add a terget="_blank". We do
                    in order to validate in XHTML 1.1 Strict.
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Credits:        Script found on Site Point (I think)
                    http://www.sitepoint.com
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -    */
    
        <!--
        function setLinkAttributes(switchLinks) {
            if (switchLinks == "true") {
                if (!document.getElementsByTagName) return;
                var anchors = document.getElementsByTagName("a");
                    for (var i=0; i<anchors.length; i++) {
                    var anchor = anchors[i];
                    
                    if (anchor.getAttribute("href") && ( anchor.getAttribute("rel") == "external" || anchor.getAttribute("rel") == "nofollow" ) ) {
                        anchor.target = "_blank";
                    }
                }
            } else {
                if (!document.getElementsByTagName) return;
                var anchors = document.getElementsByTagName("a");
                    for (var i=0; i<anchors.length; i++) {
                    var anchor = anchors[i];
                    
                    if (anchor.getAttribute("href") && ( anchor.getAttribute("rel") == "external" || anchor.getAttribute("rel") == "nofollow" ) ) {
                        anchor.target = "_self";
                    }
                }
            }
        }
        
        function toggleLinkAttributes() {
            var ExpireLongTerm = new Date();
            var ExpireLongTermValue = new Date(ExpireLongTerm.getTime()+(1000 * 60 * 60 * 360000));
            
            if ( getCookie("externalLinks") == "true" ) {
                setLinkAttributes("false");
                setCookie("externalLinks","false",ExpireLongTermValue);
            } else if (getCookie("externalLinks") == "false") {
                setLinkAttributes("true");
                setCookie("externalLinks","true",ExpireLongTermValue);
            } else if ( !getCookie("externalLinks") ) {
                setLinkAttributes("true");
                setCookie("externalLinks","true",ExpireLongTermValue);
            }
        }
        //-->

가 js 부분,  그리고 html 은
<input type="checkbox" onchange="toggleLinkAttributes();" id="toggleLinks" />

으로 해주면 가능합니다.  이용사례는 http://www.uxmag.com/ 의 오른쪽 맨 밑을 보시면 이 방법이 사용되고 있습니다.

52

(2 답글들, 지역화및 문서화 작업에 작성)

제가 다시 봐드렸습니다.  영어하는게 고수 뭐 이런거 없고 하면 하는거고 그런거니,,,  아무튼 어색한 표현들을 교정했습니다.



1  Make sure you backup your database before the procedure.
2  You take your own risks.  TatterTools does not hold any responsibilities against any corruption or loss of data.
3  This program works only with official versions of TatterTools 0.96, 0.961 and 0.97 for the migration.  Modified versions and DB structure/data by users or 3rd-party patches may not work properly.

4   The followings will be included/carried on during the process of migration.
    *  Blog posts, attachment files, comments, trackbacks, and trackback logs
    * Keywords and their attachment files
    * Site links
    * Guestbook data except icons
    * Refer log and its statistics
    * Blog statistics
    * Banner(logo) and some of blog settings
    * Spam filters
    * RSS Reader feed list




5  The migration data produced by this program can be migrated to existing TatterTools1.0 as well as newly installed TatterTools1.0

6  The migration data made by this program includes all attachment files of your blog posts, so it may have very large size resulting longer time in downloading.

7  The format of migration data is XML, and attachment files are encoded in Base-64 encoding.


8 Copyright of this program belongs to Tatter & Company.
9 License of this program is GPL.
10 You may modify this program and use it to migrate from other blogging environments.


Steps

1. (This may take a while)

53

(1 답글들, 지역화및 문서화 작업에 작성)

영어 포럼에 Justin 이라는 분께서 건의해 주셨네요.  일단 http://www.tattertools.com/en/introduce/ 의 스크린샷이 한국어 블로그들 스샷인데, 영문으로 스샷을 보여달라는 것과,  그 메뉴 제목, Share your blog 라는 문구가 선택될때는 잘려있다는 것에 대해 건의 했습니다.

54

(3 답글들, 잡담하기에 작성)

chester 작성:

포럼이 ... 이제 하루만 못봐도 ..도저히 ... 따라갈 수 없을정도로 활발하군요 ^^^

뉴욕갔다오느라 5일은 못본거 같은데 큰일입니다...

저도 영어포럼은 새로 가입했습니다.  저도 첨에는 왜 안될까 고민했었다는 ^^;;;;;

graphittie 작성:

파하하. 설치 성공했습니다. 워드 프레스 작업 끝나면 이거 작업이나 들어가 볼까요?

오오오 괜찮나요?  *_*  궁금하군요~

한국분인 Ceprix님께서 제작하신 admin 테마도 있습니다.  SpotMilk 테마입니다.  Tiger 다음으로 2번째로 인기라고 하죠 아마? 

http://www.ceprix.net/archives/plugin-s … -spotmilk/

^^ 네 맞습니다 하지만 현재 한글들이 관리자 화면에서 잘 쓰여지고 있는것으로 알고 있는데 아닌가요?
폰트크기가 12px 이상으로 폰트가 깨어져 갈때에 이미지를 생각해 봐야 하겠지만 보통 관리자 화면이나 Milfy님께서 말씀하신 한글화가 필요한 'Trackback', 'Comment', Trackback Address', 'Name', 'Password', 'Homepage' 등등은 한글표기도 문제 없는걸로 알고 있습니다.

맥퓨처 작성:
마모루 작성:

한글은 궁서, 굴림, 바탕, 돋움 정도의 4개를 기본으로 쓰고 있고
영문은 Verdana, Tahoma, Arial, Comic Sans MS, Trebuchet MS, 정도가 Windows 기본 폰트로 기억이 납니다.

문제는 한글에 있는 것이지요.
아무래도 만족스런 한글 폰트가 없다는 데 있습니다.
돋움이나 굴림 9pt 가 가장 널리 쓰이는 폰트일거라 생각하는데, 두 폰트의 모양이 같습니다.
오히려 8pt, 10pt 에서는 모서리에서 약간의 차이를 보이지만, 그 차이가 적다는 것이 문제구요.

Windows의 경우는 마모루님 말씀대로 이구요..
맥에서는 한글 font에 대해서 어떤 font를 기본으로 사용하는지가 궁금하네요.. Windows와는
다른 체계(?)로 진행이 될 듯 싶은데요.. 그럴 경우를 고려해서 한글 font쪽은 기본 font를 결정해야
할 것 같습니다..(그러고 보니 그렇게 되면 리눅스도 걸리는군요.. 한이 없네요.. smile)

음...  제가 생각하는 영단어 사용 이유는 약간 틀립니다.

안타깝게도 영어가 더 나아보이는게 사실이긴 합니다.  모든 디자이너들이 당연 하다는 듯이 영어를 선택하게 되는 이유이고, 그래서 스킨 뿐만이 아닌 거의 모든 사이트들이 영어의 사용도가 높습니다.  하지만 아시다시피 얼만큼 제작자가 이미지의 사용을 감안하면서 적절히 한글로 변화 시키느냐가 다른점일뿐, 한글 사용도 영문 사용같은 비슷한 효과를 나타낼수 있습니다.  백터폰트의 효과를 직접 가져올수 없다는걸 알았기에 일찍이 부터 한국은 이미지로 텍스트를 대체하였고, 뛰어난 디자인 감각으로 해외 사이트들보다 월등하게 멋지게 웹사이트들이 제작되고 있습니다.  편법이라고 하더래도 기술적인 부분은 거의 동등한 수준까지  표현이 가능하긴 한거죠.  '기술적으로, technically 차이가 나기 때문에 영어를 선택한다'는 요즘에는 하기 힘든 말이 되었습니다.

오히려 장애물이 있다면, 영단어를 사용할 때에 간단명료하게 표현할수 있다는 점, 웹세계에선 이미 영어로 알려지고 사용되고 있는 영단어들이 많은 점, 한글로 해석하기에는 약간 어색한 단어들이 존재한다는 점들 이라고 생각됩니다.  blogsphere 같은 것들이죠.  하지만 다행이도 위 Milfy 님께서 제시하신 단어들은 꽤 명백하게 한글로 간단명료하게 표현할수 있는 것들이고, 또한 좋은 의미와 영향도 갖는 것들이니 크게 문제될꺼 같지는 않습니다.  헌데 archive 도 블로그스피어와 같은 분류같습니다.  애매하게 뜻표현이 가능한거 같으면서 써보면 아닌거 같기도 한것들 말이죠 ^^; 

해서 저는 뜻이 제대로 전해지며 디자인에도 잘 스며든다면 여러 메뉴의 한글화는 절대 찬성입니다.

60

(11 답글들, 공지사항에 작성)

chester 작성:

하..땀뻘뻘 흘리며 장비 IDC 에 넣고 왔습니다. 왜이렇게 무거운징 ㅠ.ㅠ
이제 eolin 과 tattertools.com 이전작업을 진행하도록 하겠습니다.. ^^
어느날 문득 빨리진 느낌이 나면 신장비로 교체된것이려니 하십시오 ^

수고하셨습니다.  저도 오늘 밖에 나갔더니 왜그리 덥던지요.  걸어다니기도 힘들더군요 ㅡㅜ
아무튼 무거운거 드시느라 수고하셨습니다.  ^^

마잇 작성:
inureyes 작성:
monet 작성:

티스토리에서 작성한 글을 접속자가 볼 수는 있지만..
마우스 오른쪽 클릭이나 드래그해서 담아갈 수 없도록 했으면  합니다.
네이버 블로그의 경우 음악이나 사진을 담아갈 수 없고, 소스 마져도
볼 수가 없게 해 놓았더라구요.
또 제가 트랙백 기능을 잘 몰라서 그런지는 몰라도 싸이처럼 스크랩
기능(스크랩가능/불가)이 있었으면 합니다.

네이버 블로그도 맘만 먹으면 바로 소스 보이고 다 퍼갈 수 있습니다.
HTML의 구조상 막는 것은 본질적으로 불가능합니다. smile

inureyes님 말씀처럼 어느 정도 줄일수는 있을 테지만 근본적으로 퍼가는 것을 방지할 수는 없습니다. IE에는 현재 없지만 파이어폭스같은 경우는  javascript 옵션 조절에서 드래그나 우클릭 방지 기능을 막을 수 있습니다.

그냥 js 끄고 다니면 펌은 문제없이...  (.. )( '')  ie 도 developer's tool 로 js 끄고 다니기...

의식이 변화하는수 밖에 없습니다.  smile 

ps. 에,,, 플래쉬로 문서 작성해서 올리시고 저자 이름 크게 위에 써서 파일로 만드신 후에 포스팅에 올리시면 혹시나,,,

딘제 작성:
유마 작성:

그리고, 저는 html 나 css 를 몰라서 그러는데... css 를 끌 수도 있습니까? 현재 태터에서?

브라우저에서 끌 수도 있을거에요. 파폭이나 오페라는 알겠는데 IE가 돼는지 안 돼는지는...

네 css 를 끄는것은 극소수의 사이트에서 지원하기도 하지만 보통 브라우저에서 끕니다.  파이어폭스, 오페라등의 브라우저에서 가능하며 인터넷 익스플로러는 Add-on 을 써야 가능합니다.  Developer's Tool 이라는 add on 을 다운받으시면 가능합니다.  생각해 보니 IE7 도 이부분은 첨가하지 않았군요.  ㅡㅜ

63

(30 답글들, 잡담하기에 작성)

chester님 말씀 너무 멋진데요.  좋은 수확도 있고 결실도 맺는 그런 한해, 그런 앞날이 되기를.  smile

64

(16 답글들, 잡담하기에 작성)

워프에는 스펨이 100개 넘개 달리기도 합니다....  oTL

^^ inureyes 님 말씀대로 플러그인 까지 가지 않아도 body id 로 구현이 가능합니다  1.06 이 기대되는군요 ^^

잘 알았습니다.  smile
약간의 비전이나마 볼수 있어서 질문을 잘했다는 생각이 마구 듭니다.  ^^
좋은 발전있으면 좋겠네요.

새롭게 tistory 가 알파 서비스를 들어가면서 대문도 블로그로 변화하였습니다.
저는 블로거로써 크게 불편이나 어색한것이 없지만, 과연 대중성을 생각할 때에 tistory 의 메인 웹사이트를 블로그로 내어놓아도 되는것인가 라는 생각이 들었습니다.

rooine 작성:

재미있는 사실이 있는데, 기존의 블로그를 이용하시던 분들은 티스토리 관련 뉴스에 촉각을 곤두세우는 편이라고 가정하면,
블로그를 이용하지 않던 사람들은 사실조차도 모르거니와, 설명을 해 줘도 시큰둥.. -_-+

몇몇 사람에게만 관심이 집중되는 서비스가 되지 말아야 할텐데.... 걱정입니다 후후;;

참 저도 많이 느꼈습니다.  블로거들의 축제(?) 가 되고 있는 듯한 느낌에 말이죠.  이러한 상황 가운데에 대중에게 블로그를 소개시켜줄, 블로그와의 첫 대면을 tistory 로 하기엔 이용자가 부담감을 갖는다거나 거부감까지 느낄수 있다고 생각이 됩니다만  저만의 생각인지 모르겠네요.  특히나 많은 여성 인터넷 사용자 분들은 블로그 라는 툴이 너무 '복잡하다' 라고 생각하시는 분들이 꽤 되시는걸 아는데, 처음으로 블로그를 사용하고자 하는 이에게 블로그로 제시하는것이 아니라 익숙한 홈페이지 스타일로 잘 이끌어 줄수 있는 첫페이지가 되면 좋겠다는 의견을 내어 봅니다.  '블로그는 무엇인가' '블로그의 장점' 등을 잘 소개시켜줄 만한 페이지를 담은 웹사이트가 어떨지요.  smile

딘제 작성:
건더기 작성:

이러다가 1.0.6 릴리즈되면 스킨계에 피바람이 불듯....:cool:

아마도요...:| 하지만 디자인이 더 다양해질 수 있다는 측면에서는 big_smile

예전에 TT 1.0 출시되면 스킨하나 만든다고 했는데  이번에 body id 도 결정되고 관리자 고유id 도 첨부되면 정말 하나 제작해야겠군요~

69

(12 답글들, 티스토리(TiStory.com)에 작성)

아 안타깝게도 떨어졌군요.  다음 기회에 smile

다른 이야기 입니다만 TT 에 기본스킨에서 블로그 제목을 나타내는 h1 부분뒤에 br 태그가 담겨있는데 hx 태그는 끝나면 저절로 새줄로 바꿔주니 때어내어도 되지 않을까 하는 생각입니다.  잡이야기 이긴 합니다 ㅡㅡ;;

70

(11 답글들, 스킨 및 플러그인에 작성)

의견을 덧붙이자면  말씀하신데로 category_#_# 식이나 혹은 더 짧게 줄여  ctg#-#  이런식도 괜찮을듯합니다. 

이유인즉, 일단 페이지 안에서 한번밖에 쓰이지 않는 id 라는 특성때문에 혹 이 부분을 모르는 유저가 같은 이름을 지정한다면  에러가 나는 낭패가 나오게 됩니다.  예를들어  원래 skin.html 안에  id="profile" 을 만들었는데  body 에서도 id로 profile 을 부르게 되면 에러가 나기때문에,,

약간은 복잡해도 괜찮을듯 싶습니다.  뭐 스킨 제작하시는 분들이라면 그정도는 감안하고 이해하실듯 합니다만,,  어느정도 통일성만 있다면 말이죠

음 일단 왜 ul 부분에 id 가 필요 없는지에 대해는 위에서 설명드렸듯이 디자인에 큰 영향을 미치는 부분은 아닙니다. 

그리고 이미 위에서 말씀드린 소스로 나니님의 문제는 도와드렸습니다.  제가 수많은 테마제작이나 사이트 제작을 해봤지만 메뉴부분에서 하위 ul 까지 id 로 정해준다는건 약간은 지나친세심함 입니다.  1px, 1px 조절하여 구현해야하는 부분이라 하더래도 리스트의 조절은 상위 선택자부터 시작하여 잡아주는것이 원칙아닌 원칙입니다.

72

(11 답글들, 스킨 및 플러그인에 작성)

빈공간은 허용치 않구요 한글은 ie 에서는 먹히지 않네요.

73

(11 답글들, 스킨 및 플러그인에 작성)

오오 !!  드디어 놀라운 세계

그 부분에 관한 포스팅이나 함 올려봐야겠군요.  5시,, 그렇네요..저야 미국이니 괜찮지만,,   수고하셨습니다.

74

(11 답글들, 스킨 및 플러그인에 작성)

밑에 graphittie 님께서 내어주신 의견입니다.

body에 카테고리 속성에 따라 id를 주는 것이 좋지 않을까 합니다. 메인 메뉴가 탭 속성으로 설정되도록 하는데 id를 이용하면 좋더군요. 대부분의 사이트에서도 사용하는 방식입니다. 이 메인 메뉴라는 것이 이용자의 입맛에 따라 변할 수 있는 것이니 직접 소스코드 넣는 것보다 플러그인 형태로 넣어 보다 쉽게 변경할 수 있도록 하는 편이 좋을 것 같습니다.

아이디어를 더 펼쳐보자면, 일단 body id 를 적용함으로써 메뉴뿐만이 아닌 조금은 간단한 테터 스킨의 변화에 다양성을 주자는 것입니다.

아쉽게도 테터가 워드프레스 만큼의 각각의 페이지 제어가 되지 않습니다.  아시다시피 single.php 나 page 개념, 여러가지 등으로 거의 모든 페이지를 다르게 구성이 가능하지요.  거기서 출발해서 정말 다양하고 멋진 사이트 구축이 됩니다.  부러운 툴입니다만, 테터에서도 왠만큼은 가능할수 있다고 생각이됩니다.  예를들어 메인 페이지에는 1의 형태로 보여주고 카테고리 #2 를 보여줄때에는 완전 다른 디자인을 보여주고 말이죠.  한개의 skin.html 으로도 모든걸 가능케 할수 있습니다. 

오예!!

body id 의 지정으로 그 모든것이 가능하느냐. 넵.  graphittie 님의 말씀대로 적어도 각각의 카테고리별로 body id 가 정해질수 있다면 그 표현은 정말 무궁무진합니다.  그것 하나만으로도 워드프레스의 page 라는 개념을 따라할수 있을정도 까지 갈수 있다고 생각이 됩니다.

다음 업데이트때에는 이러한 body id 의 지정이 꼭 첨가되면 좋겠네요.  아마도 많은 변화가 일어날수 있다고 생각이 됩니다.  혹시나 구현 설명을 원하시면 다음을 읽어주세요.



body id 의 사용은 이렇습니다. 메인 인덱스 페이지에는 id 이름을 TT 로 주고, 카테고리1에는 id 를 TT-1, 카테고리 2 에는 TT-2 를 준다고 가정할때에
3개의 모든 페이지가 같은 HTML 을 가지고 있다고 칩시다.  TT 가 많이 그러한 경우죠.  skin.html 만 있으니.

<body id="TT">
<h1>비행기</h1>
<div id="graphic">비행기는 높아 높으면 백두산...</div>

이러한 HTML 을 3페이지가 똑같이 가지고 있을때에 BODY ID 만 바뀜으로 모든것을 제어가 가능합니다.  선택자 앞에 BODY ID 를 적어주면 되거든요. 

자 css 에서 메인 페이지를 컨트롤하려면  #TT #graphic {font-size: 100px;} 를 주어 폰트를 100PX 로 보여줍니다. div 선택자 앞에 body id 인 #TT 가 붙어있죠.

그리고 카테고리1을 보여줄시에는 폰트색깔이 RED 로 보여준다면

#TT-1 #graphic {color:red;}

으로, 그리고 카테고리 2를 보여줄때엔 h1 비행기를 보여주지 말자, 라면

#TT-2 #graphic h1 {display:none;}

으로 해주면 됩니다.  같은 html 인데도 css 로 모든 변화를 주었죠.

그렇다면 프로필 페이지를 TT 에서 구현한다 라고 생각하면, profile 이라는 포스팅을 만든후에, public 으로는 하되 sync 는 하지 않아서 공개하면서 그 페이지만 완전한 변화를 줄수 있을테니 워드프레스와 같은 page 가 생성이 되는것이죠. 


길게 설명을 했습니다만 body id 의 설정이 가능하다면 스킨의 다이나믹한 요소에 큰 도움이 될꺼 같습니다.  의견 부탁드립니다  smile

daybreaker님께서 TT 개발을 돕고 계시는줄 몰랐군요 ^^;
웹표준에는 저도 관심이 많고해서,,  키보드에 손을 댑니다.

사실 모든 사람이 그 표준안에 맞출 필요는 없습니다. 이상이 구현되어 현실을 발전시키지만, 현실은 그 자체로 생명이 있습니다.

라고 inureyes님께서 말씀하셨듯이 웹표준 이라는것 자체가 강요가 아닌 일단 권고안 이라는것입니다.  옛날 어느 포털사이트에서 웹표준에 맞추려 해도 지원하는 언어에서 output 자체가 표준에 어긋나고 있었기때문에 골치아파 하시길래  "하지마세요" 라고 말씀드렸습니다.  ㅡㅡ

"웹표준 준수" 라는것이  html4.01 로 준수하더래도 준수 하는것 이라고 생각합니다.  물론 w3에서 권하는것은 strict 모드이긴 하지만 말입니다.  하지만 브라우저의 기술들도 제대로 변화되지 않았고, (아직도 죽쓰고 있는 ie) 표준 지원에 방해가 되는 언어들도 아직 있기때문에 최대한 변화할수 있는 한에서 그리고 지킬수 있는 안에서 하라는 것이지  무조건 1.1 버전을 준수하라는건 절대 아닙니다.  뭐 eric meyer 는 브라우저에서 각각 다르게 보여도 괜찮다고 하지만, (워낙 그분은 정보전달에 우선순위를 두는,,) 디자인을 하는 사람들에게는 그건 아니니까요. 

전 TT 의 노력으로 최대한 '웹표준' 이라는것의 걸음은 맞추려고 노력하시는것 멋지다고 생각됩니다.  그래서 1.1의 준수까지 가시는거 막지는 않습니다만 제 경험에 의하면 노력에 비해 결과는 별로라고 생각하고 있습니다.  제 홈같은 단순한 집에서야 1.1이 괜찮긴 합니다만,,  1.0 tradition 에도 감격이라고 말씀드리고 싶네요.  위에서 언급하셨듯이 문서와 프레젠테이션 분리는 필요하겠으나 너무 집착때문에 머리털이 빠지시면 "마이너스"라고 생각됩니다.  smile

덧붙이자면,, 
daybreaker 님께서 생각하시는 각각의 ul 에 id 를 주시는건 음,,,  정말 정교한 디자인을 원하시는 유저가 아니라면 솔직히는 필요없다고 생각이 됩니다.  그리고 그럴만한 이유도 적다고 생각이 됩니다.  카테고리 부분은 어느정도 패턴이 동일해야 되기 때문에 그정도의 부분까지 한다면 오히려 역효과가 나올수도 있겠네요.

일단 카테고리 제어가 CSS 에서   
메인 카테고리 선택 에는 #category_list ul li {어쩌구}  와
sub 카테고리 선택에는 #category_list ul li ul li {어쩌구}
로 선택이 가능하니 일단은 큰 어려움은 없다고 생각이 됩니다.

주절주절 썼네요 아무튼 수고들 하십니다